home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Standards 1994 January / InfoMagic Standards - January 1994.iso / ccitt / 1988 / troff / 8_2_05.tro < prev    next >
Text File  |  1991-12-22  |  133KB  |  3,983 lines
  1. .rs
  2. .\" Troff code generated by TPS Convert from ITU Original Files
  3. .\"                 Not Copyright (~c) 1991 
  4. .\"
  5. .\" Assumes tbl, eqn, MS macros, and lots of luck.
  6. .TA 1c 2c 3c 4c 5c 6c 7c 8c
  7. .ds CH
  8. .ds CF
  9. .EQ
  10. delim @@
  11. .EN
  12. .nr LL 40.5P
  13. .nr ll 40.5P
  14. .nr HM 3P
  15. .nr FM 6P
  16. .nr PO 4P
  17. .nr PD 9p
  18. .po 4P
  19.  
  20. .rs
  21. \v'|.5i'
  22. .LP
  23. \fBMONTAGE : \(sc 2.4.8.6 EN T\*\|ETE DE CETTE PAGE\fR 
  24. .sp 1P
  25. .LP
  26. \v'10P'
  27. 2.5
  28.     \fIMultilink procedure\fR \fI(MLP) (\fR \fISubscription\(hytime\fR 
  29. \fIselectable option\fR \fI)\fR 
  30. .sp 9p
  31. .RT
  32. .PP
  33. The multilink procedure (MLP) exists as an added upper sublayer of the 
  34. Data Link Layer, operating between the Packet Layer and a multiplicity 
  35. of single data link protocol functions (SLPs) in the Data Link Layer (see 
  36. Figure\ 1/X.25).
  37. .EF '%    Fascicle\ VIII.2\ \(em\ Rec.\ X.25''
  38. .OF '''Fascicle\ VIII.2\ \(em\ Rec.\ X.25    %'
  39. .PP
  40. A multilink procedure (MLP) must perform the functions of accepting
  41. packets from the Packet Layer, distributing those packets across the available 
  42. DCE or DTE\ SLPs for transmission to the DTE or DCE\ SLPs, respectively, 
  43. and 
  44. resequencing the packets received from the DTE or DCE\ SLPs for delivery 
  45. to the DTE or DCE Packet Layer, respectively. 
  46. .RT
  47. .LP
  48. .rs
  49. .sp 26P
  50. .ad r
  51. \fBFigure 1/X.25, p.\fR 
  52. .sp 1P
  53. .RT
  54. .ad b
  55. .RT
  56. .LP
  57. .bp
  58. .sp 1P
  59. .LP
  60. 2.5.1
  61.     \fIField of application\fR 
  62. .sp 9p
  63. .RT
  64. .PP
  65. The optional multilink procedure (MLP) described below is used for data 
  66. interchange over one or more single link procedures (SLPs), each 
  67. conforming to the description in \(sc\(sc\ 2.2, 2.3 and 2.4, in parallel 
  68. between a DCE and a DTE. The multilink procedure provides the following 
  69. general 
  70. features:
  71. .RT
  72. .LP
  73.     a)
  74.     achieve economy and reliability of service by providing
  75. multiple SLPs between DCE and a DTE;
  76. .LP
  77.     b)
  78.     permit addition and deletion of SLPs without interrupting
  79. the service provided by the multiple SLPs;
  80. .LP
  81.     c)
  82.     optimize bandwidth utilization of a group of SLPs through
  83. load sharing;
  84. .LP
  85.     d)
  86.     achieve graceful degradation of service when an SLP(s)
  87. fails;
  88. .LP
  89.     e)
  90.      provide each multiple SLP group with a single logical Data Link Layer 
  91. appearance to the Packet Layer; and 
  92. .LP
  93.     f
  94. )
  95.      provide resequencing of the received packets prior to delivering them 
  96. to the Packet Layer. 
  97. .sp 1P
  98. .LP
  99. 2.5.2
  100.     \fIMultilink frame\fR \fIstructure\fR 
  101. .sp 9p
  102. .RT
  103. .PP
  104. All information transfers over an SLP are in multilink frames
  105. conforming to one of the formats shown in Table\ 9/X.25.
  106. .RT
  107. .LP
  108. .rs
  109. .sp 16P
  110. .ad r
  111. \fBTable 9/X.25 (comme figure), p.\fR 
  112. .sp 1P
  113. .RT
  114. .ad b
  115. .RT
  116. .sp 1P
  117. .LP
  118. 2.5.2.1
  119.     \fIMultilink control field\fR 
  120. .sp 9p
  121. .RT
  122. .PP
  123. The multilink control field (MLC) consists of two octets, and its contents 
  124. are described in \(sc\ 2.5.3. 
  125. .RT
  126. .sp 1P
  127. .LP
  128. 2.5.2.2
  129.     \fIMultilink information field\fR 
  130. .sp 9p
  131. .RT
  132. .PP
  133. The information field of a multilink frame, when present, follows the MLC. 
  134. See \(sc\(sc\ 2.5.3.2.3 and\ 2.5.3.2.4 for the various codings and groupings 
  135. of bits in the multilink information field. 
  136. .RT
  137. .sp 2P
  138. .LP
  139. 2.5.3
  140.     \fIMultilink control field format and parameters\fR 
  141. .sp 1P
  142. .RT
  143. .sp 1P
  144. .LP
  145. 2.5.3.1
  146.     \fIMultilink control field format\fR 
  147. .sp 9p
  148. .RT
  149. .PP
  150. The relationship shown in Table 10/X.25 exists between the order of bits 
  151. delivered to/received from an SLP and the coding of the fields in the 
  152. multilink control field.
  153. .RT
  154. .sp 1P
  155. .LP
  156. 2.5.3.2
  157.     \fIMultilink control field parameters\fR 
  158. .sp 9p
  159. .RT
  160. .PP
  161. The various parameters associated with the multilink control
  162. field format are described below. See Table\ 10/X.25 and
  163. Figure\ 2/X.25.
  164. .bp
  165. .RT
  166. .LP
  167. .rs
  168. .sp 19P
  169. .ad r
  170. \fBTableau 10/X.25 (comme figure), p. 3\fR 
  171. .sp 1P
  172. .RT
  173. .ad b
  174. .RT
  175. .LP
  176. .rs
  177. .sp 31P
  178. .ad r
  179. \fBFigure 2/X.25, p. 4\fR 
  180. .sp 1P
  181. .RT
  182. .ad b
  183. .RT
  184. .LP
  185. .bp
  186. .sp 1P
  187. .LP
  188. 2.5.3.2.1
  189.     \fIVoid sequencing bit (V)\fR 
  190. .sp 9p
  191. .RT
  192. .PP
  193. The 
  194. void sequencing bit (V)
  195. indicates if a received
  196. multilink frame shall be subjected to sequencing constraints. V set to\ 
  197. 1 means sequencing shall not be required. V set to\ 0 means sequencing 
  198. shall be 
  199. required.
  200. .PP
  201. \fINote\fR \ \(em\ For purposes of this Recommendation, this bit shall be set
  202. to\ 0.
  203. .RT
  204. .sp 1P
  205. .LP
  206. 2.5.3.2.2
  207.     \fISequence check option bit (S)\fR 
  208. .sp 9p
  209. .RT
  210. .PP
  211. The 
  212. sequence check option bit (S)
  213. is only significant when V is set to\ 1 (indicating that sequencing of 
  214. received multilink frames shall 
  215. not be required). S set to\ 1 shall mean no MN(S) number has been assigned.
  216. S\ set to\ 0 shall mean an MN(S) number has been assigned, so that although
  217. sequencing shall not be required, a duplicate multilink frame check may be
  218. made, as well as a missing multilink frame identified.
  219. .PP
  220. \fINote\fR \ \(em\ For purposes of this Recommendation, this bit shall be set
  221. to\ 0.
  222. .RT
  223. .sp 1P
  224. .LP
  225. 2.5.3.2.3
  226.     \fIMLP reset request bit (R)\fR 
  227. .sp 9p
  228. .RT
  229. .PP
  230. The 
  231. MLP reset request bit (R)
  232. is used to request a
  233. multilink reset (see \(sc\ 2.5.4.2). R set to\ 0 is used in normal communication, 
  234. i.e.\ no request for a multilink reset. R set to 1 is used by the DCE MLP 
  235. or DTE MLP to request the reset of the DTE MLP or DCE MLP state variables, 
  236. respectively. In this R\ =\ 1\ case, the multilink information field does not
  237. contain Packet Layer information, but may contain an optional 8\ bit Cause 
  238. Field that incorporates the reason for the reset. 
  239. .PP
  240. \fINote\fR \ \(em\ The encoding of the Cause Field is a subject for further
  241. study.
  242. .RT
  243. .sp 1P
  244. .LP
  245. 2.5.3.2.4
  246.     \fIMLP reset confirmation bit (C)\fR 
  247. .sp 9p
  248. .RT
  249. .PP
  250. The MLP 
  251. reset confirmation bit (C)
  252. is used in reply to an R bit set to\ 1 (see \(sc\ 2.5.3.2.3) to confirm 
  253. the resetting of the multilink state variables (see \(sc\ 2.5.4.2). C set 
  254. to\ 0 is used in normal communications, 
  255. i.e.\ no multilink reset request has been activated. C set to\ 1 is used 
  256. by the DCE MLP or DTE MLP in reply to a DTE MLP or DCE MLP multilink frame, 
  257. respectively, with R set to\ 1, and indicates that the DCE MLP or DTE MLP 
  258. state variable reset process has been completed by the DCE or DTE, respectively. 
  259. In this C\ =\ 1 case, the multilink frame is used without an information 
  260. field.
  261. .RT
  262. .sp 1P
  263. .LP
  264. 2.5.3.2.5
  265.     \fIMultilink send state variable MV(S)\fR 
  266. .sp 9p
  267. .RT
  268. .PP
  269. The 
  270. multilink send state variable MV(S)
  271. denotes the
  272. sequence number of the next in\(hysequence multilink frame to be assigned to an
  273. SLP. This variable can take on the value 0 through 4095 (modulo\ 4096). The
  274. value of MV(S) is incremented by 1 with each successive multilink frame
  275. assignment.
  276. .RT
  277. .sp 1P
  278. .LP
  279. 2.5.3.2.6
  280.     \fIMultilink sequence number MN(S)\fR 
  281. .sp 9p
  282. .RT
  283. .PP
  284. Multilink frames contain the 
  285. multilink sequence number
  286. MN(S)
  287. . Prior to the assignment of an in\(hysequence multilink frame to an
  288. available SLP, the value of MN(S) is set equal to the value of the multilink
  289. send state variable MV(S). The multilink sequence number is used to resequence 
  290. and to detect missing and duplicate multilink frames at the receiver before 
  291. the contents of a multilink frame information field is delivered to the 
  292. Packet 
  293. Layer.
  294. .RT
  295. .sp 1P
  296. .LP
  297. 2.5.3.2.7
  298.     \fITransmitted multilink frame acknowledged state\fR 
  299. \fIvariable MV(T)\fR 
  300. .sp 9p
  301. .RT
  302. .PP
  303. MV(T) is the state variable at the transmitting DCE MLP or DTE MLP denoting 
  304. the oldest multilink frame which is awaiting an indication that a DCE SLP 
  305. or DTE SLP has received an acknowledgement from its remote DTE SLP or DCE 
  306. SLP, respectively. This variable can take on the value 0 through 4095 
  307. (modulo\ 4096). Some multilink frames with sequence numbers higher than MV(T)
  308. may already have been acknowledged.
  309. .RT
  310. .sp 1P
  311. .LP
  312. 2.5.3.2.8
  313.     \fIMultilink receive state variable MV(R)\fR 
  314. .sp 9p
  315. .RT
  316. .PP
  317. The 
  318. multilink receive state variable MV(R)
  319. denotes the
  320. sequence number at the receiving DCE MLP or DTE MLP of the next in\(hysequence
  321. multilink frame to be received and delivered to the Packet Layer. This 
  322. variable can take on the value\ 0 through\ 4095 (modulo\ 4096). The value 
  323. of MV(R) is 
  324. updated as described in \(sc\ 2.5.4.3.2 below. Multilink frames with higher
  325. sequence numbers in the DCE MLP or DTE MLP receive window may already have 
  326. been received. 
  327. .bp
  328. .RT
  329. .sp 1P
  330. .LP
  331. 2.5.3.2.9
  332.     \fIMultilink window size MW\fR 
  333. .sp 9p
  334. .RT
  335. .PP
  336. MW is the maximum number of sequentially numbered multilink frames that 
  337. the DCE MLP or DTE MLP may transfer to its SLPs beyond the lowest numbered 
  338. multilink frame which has not yet been acknowledged. MW is a system parameter 
  339. which can never exceed 4095\ \(em\ MX. The value of MW shall be agreed 
  340. for a period of time with the Administration and shall have the same value 
  341. for both the 
  342. DCE\ MLP and the DTE MLP for a given direction of information transfer.
  343. .PP
  344. \fINote\fR \ \(em\ Factors which will affect the value of parameter MW 
  345. include, but are not limited to, single link transmission and propagation 
  346. delays, the 
  347. number of links, the range of multilink frame lengths, and SLP parameters 
  348. N2, T1, and\ k. 
  349. .PP
  350. The MLP transmit window contains the sequence numbers MV(T) to MV(T) + 
  351. MW\ \(em\ 1 inclusive. 
  352. .PP
  353. The MLP receive window contains the sequence numbers MV(R) to MV(R) + MW\ 
  354. \(em\ 1 inclusive. Any multilink frame received within this window shall 
  355. be 
  356. delivered to the Packet Layer when its MN(S) becomes the same as
  357. MV(R).
  358. .RT
  359. .sp 1P
  360. .LP
  361. 2.5.3.2.10\ \ 
  362. \fIReceive MLP window guard region MX\fR 
  363. .sp 9p
  364. .RT
  365. .PP
  366. MX is a system parameter which defines a guard region of multilink sequence 
  367. numbers of fixed size beginning at MV(R)\ +\ MW. The range of MX shall 
  368. be large enough for the receiving MLP to recognize the highest MN(S) outside 
  369. of its receive window that it may legitimately receive after a multilink 
  370. frame 
  371. loss has occurred.
  372. .PP
  373. A multilink frame with sequence number MN(S)\ =\ Y received in this
  374. guard region indicates that those missing multilink frame(s) in the range 
  375. MV(R) to Y\ \(em\ MW has(have) been lost. MV(R) is then updated to Y\ \(em\ 
  376. MW\ +\ 1. 
  377. .PP
  378. \fINote\fR \ \(em\ A number of methods may be selected in calculating a value
  379. for the guard region MX:
  380. .RT
  381. .LP
  382.     a)
  383.     In a system where the transmitting MLP assigns \fIh\fR\d\fIi\fR\u\|
  384. in\(hysequence contiguous multilink frames at a time to the
  385. \fIi\fR th SLP, MX should be greater than or equal to the
  386. sum of the \fIh\fR\d\fIi\fR\u\ +\ 1\ \(em\ \fIh\fR\d\fIm\fR\\d\fIi\fR\\d\fIn\fR\u, 
  387. where 
  388. \fIh\fR\d\fIm\fR\\d\fIi\fR\\d\fIn\fR\uequals the smallest \fIh\fR\d\fIi\fR\uencountered. 
  389. Where there are \fIL\fR \ SLPs in the multilink group, MX should
  390. be greater than or equal to:
  391. \v'6p'
  392. .sp 1P
  393. .ce 1000
  394. @ pile {\fIL\fR above sum above \fIi\fR =1
  395. } @ \fIh
  396. \di\u\fR + 1 = \fIh
  397. \dmin
  398. \u\fR ; or
  399. .ce 0
  400. .sp 1P
  401. .LP
  402. .sp 1
  403.     b)
  404.     In a system where the transmitting MLP assigns on a rotation
  405. basis \fIh\fR \| in\(hysequence contiguous multilink frames at a time to
  406. each SLP, MX at the receiving MLP should be greater than or
  407. equal to \fIh\fR (\fIL\fR \ \(em\ 1)\ +\ 1, where \fIL\fR is the number of SLPs
  408. in the multilink group; or
  409. .LP
  410.     c)
  411.     MX should be no larger than MW.
  412. .LP
  413. Additional methods of selecting MX values are for further
  414. study.
  415. .sp 1P
  416. .LP
  417. 2.5.4
  418.     \fIDescription of \fR \fImultilink procedure (MLP)\fR 
  419. .sp 9p
  420. .RT
  421. .PP
  422. The procedure below is presented from the perspective of the
  423. transmitter and receiver of multilink frames.
  424. .PP
  425. The arithmetic is performed modulo 4096.
  426. .RT
  427. .sp 1P
  428. .LP
  429. 2.5.4.1
  430.     \fIInitialization\fR 
  431. .sp 9p
  432. .RT
  433. .PP
  434. The DCE or DTE will perform an MLP initialization by first
  435. resetting MV(S), MV(T) and MV(R) to zero and then initializing each of its
  436. SLPs. Upon successful initialization of at least one of the SLPs, the DCE
  437. shall, and the DTE should, perform the multilink resetting procedure as
  438. described in \(sc\ 2.5.4.2. An SLP initialization is performed according to
  439. \(sc\ 2.4.4.1 of this Recommendation.
  440. .PP
  441. \fINote\fR \ \(em\ An SLP that cannot be initialized should be declared 
  442. out of service and appropriate recovery action should be taken. 
  443. .RT
  444. .sp 1P
  445. .LP
  446. 2.5.4.2
  447.     \fIMultilink resetting\fR \fIprocedure\fR 
  448. .sp 9p
  449. .RT
  450. .PP
  451. The multilink resetting procedure provides the mechanism for
  452. synchronizing the sending and receiving MLPs in both the DCE and the DTE, 
  453. when deemed necessary by either the DCE or the DTE. Exact cases where the 
  454. MLP 
  455. resetting procedures are invoked is for further
  456. .bp
  457. .PP
  458. study. Following a
  459. successful
  460. multilink resetting procedure, the multilink sequence numbering in each
  461. direction begins with the value\ 0. Appendix\ III provides examples of the
  462. multilink resetting procedures when initiated by either the DCE or the 
  463. DTE, or by both the DCE and the DTE simultaneously. 
  464. .PP
  465. A multilink frame with R\ =\ 1 is used to request multilink reset, and 
  466. a multilink frame with C\ =\ 1 confirms that the multilink reset process 
  467. has been completed. An MLP resets MV(S) and MV(T) to zero on transfer of 
  468. a multilink 
  469. frame with R\ =\ 1; and resets MV(R) to zero on receipt of a multilink 
  470. frame with R\ =\ 1. 
  471. .PP
  472. When the DCE MLP or DTE MLP initiates the resetting procedure, it
  473. removes all of the unacknowledged multilink frames that are held in that MLP
  474. and its associated SLPs, and retains control of those frames. Hereafter, the
  475. initiating MLP does not transfer a multilink frame with R\ =\ C\ =\ 0 until the
  476. reset process is completed. (One method to remove multilink frames in the 
  477. SLP is to disconnect the data link of that SLP.) The initiating MLP then 
  478. resets its multilink send state variable MV(S) and its transmitted multilink 
  479. frame 
  480. acknowledged state variable MV(T) to zero. The initiating MLP then transfers 
  481. a multilink frame with R\ =\ 1 as a reset request on one of its SLPs and 
  482. starts 
  483. Timer\ MT3. The value of the MN(S) field in the R\ =\ 1 frame may be any value,
  484. since when R\ =\ 1 the MN(S) field is ignored by the receiving MLP. The
  485. initiating MLP continues to receive and process multilink frames from the
  486. remote MLP, in accordance with the procedures as described in \(sc\ 2.5.4.4 
  487. below until it receives a multilink frame with R\ =\ 1 from the remote 
  488. MLP. 
  489. .PP
  490. An MLP which has received a multilink frame with R\ =\ 1 (reset request) 
  491. in the normal communication status from an initiating MLP starts the operation 
  492. as described above; the MLP should receive no multilink frame with R\ =\ 
  493. C\ =\ 0 
  494. from the other MLP until the reset process is completed. Any such multilink
  495. frame received is discarded. When an MLP has already initiated its own
  496. multilink resetting procedure and has transferred the multilink frame with
  497. R\ =\ 1 to one of its SLPs for transmission, that MLP does not repeat the 
  498. above operation upon receipt of a multilink frame with R\ =\ 1 from the 
  499. other 
  500. MLP.
  501. .PP
  502. Receipt of a frame with R\ =\ 1 (reset request) causes the receiving MLP 
  503. to deliver to the Packet Layer those packets already received and to identify 
  504. those multilink frames assigned to SLPs but unacknowledged. The Packet 
  505. Layer 
  506. may be informed of the packet loss at the original value of MV(R) and at any
  507. subsequent value(s) of MV(R) for which there has been no multilink frame
  508. received up to and including the highest numbered multilink frame received.
  509. The receiving MLP then resets its multilink receive state variable MV(R) to
  510. zero.
  511. .PP
  512. After an MLP assigns a multilink frame with R\ =\ 1 to one of its SLPs, 
  513. it shall receive indication of successful or unsuccessful transmission 
  514. from 
  515. that SLP as one of the conditions before transferring a multilink frame with
  516. C\ =\ 1; when the initiating MLP then receives a multilink frame with R\ 
  517. =\ 1, and has completed the multilink state variable resetting operation 
  518. described above, the initiating MLP transfers a multilink frame with C\ 
  519. =\ 1 (reset confirmation) to the other MLP. When an MLP has: 
  520. .RT
  521. .LP
  522.     (1) 
  523.     received a multilink frame with R\ =\ 1,
  524. .LP
  525.     (2) 
  526.     transferred a multilink frame with R\ =\ 1 on one of its
  527. SLPs, and
  528. .LP
  529.     (3) 
  530.     completed the multilink state variable resetting operation
  531. above,
  532. .LP
  533. that MLP then transfers a multilink frame with C\ =\ 1 (reset confirmation) to
  534. the other MLP as soon as possible, given that indication of the successful 
  535. or unsuccessful transmission of the R\ =\ 1 multilink frame has been received 
  536. from that MLP's SLP. The C\ =\ 1 multilink frame is a reply to the multilink 
  537. frame 
  538. with R\ =\ 1. The value of the MN(S) field in the above C\ =\ 1 frame may 
  539. be any 
  540. value, since when C\ =\ 1 the MN(S) field is ignored by the receiving MLP. The
  541. multilink sequence number MN(S) received in each direction following multilink 
  542. reset will begin with the value zero. 
  543. .PP
  544. When an MLP uses only one SLP to transmit the multilink frame with R\ =\ 
  545. 1 and the multilink frame with C\ =\ 1, the MLP can transfer the multilink 
  546. frame with C\ =\ 1 immediately after the multilink frame with R\ =\ 1 without
  547. waiting for SLP indication of transmission completion. An MLP shall not
  548. retransmit a multilink frame with R\ =\ 1 or a multilink frame with C\ 
  549. =\ 1 unless Timer MT3 (see \(sc\ 2.5.5.3 below) runs out. An MLP may use 
  550. two different SLPs as long as one is used for transmitting the multilink 
  551. frame with R\ =\ 1 and the 
  552. other is used for transmitting the multilink frame with C\ =\ 1 following 
  553. receipt of the SLP indication of successful or unsuccessful transmission 
  554. of the R\ =\ 1 multilink frame. A multilink frame with R\ =\ C\ =\ 1 is 
  555. never used. 
  556. .PP
  557. When an MLP receives the multilink frame with C\ =\ 1, the MLP stops its 
  558. Timer\ MT3. The transmission of the multilink frame with C\ =\ 1 to a remote 
  559. SLP and the reception of a multilink frame with C\ =\ 1 from the remote 
  560. MLP completes the multilink resetting procedure for an MLP. The first multilink 
  561. frame 
  562. transferred with R\ =\ C\ =\ 0 shall have a multilink sequence number MN(S) 
  563. value of zero. After an MLP transfers a multilink frame with C\ =\ 1 to 
  564. an SLP, the MLP may receive one or more multilink frames with R\ =\ C\ 
  565. =\ 0. After an MLP receives a multilink frame with C\ =\ 1, the MLP may 
  566. transfer one or more multilink frames with R\ =\ C\ =\ 0 to its SLPs. 
  567. .bp
  568. .PP
  569. When an MLP additionally receives one or more multilink frames with
  570. R\ =\ 1 between receiving a multilink frame with R\ =\ 1 and transferring a
  571. multilink frame with C\ =\ 1, the MLP shall discard the extra multilink frames
  572. with R\ =\ 1. When an MLP receives a multilink frame with C\ =\ 1, which 
  573. is not a reply to a multilink frame with R\ =\ 1, the MLP shall discard 
  574. the multilink 
  575. frame with C\ =\ 1.
  576. .PP
  577. After an MLP transfers a multilink frame with C\ =\ 1 on one of its
  578. SLPs, the MLP may receive a multilink frame with R\ =\ 1 from the other 
  579. MLP. The MLP shall regard the multilink frame with R\ =\ 1 as a new reset 
  580. request and 
  581. shall start the multilink resetting procedure from the beginning. When 
  582. an MLP which has not received a multilink frame with R\ =\ 1, transfers 
  583. a multilink 
  584. frame with R\ =\ 1, and therefore receives a multilink frame with C\ =\ 
  585. 1, the MLP shall restart the resetting procedure from the beginning. 
  586. .PP
  587. When Timer MT3 runs out, the MLP restarts the multilink resetting
  588. procedure from the beginning. The value of Timer MT3 shall be large enough 
  589. to include the transmission, retransmission and propagation delays in the 
  590. SLPs, 
  591. and the operation time of the MLP that receives a multilink frame with R\ =\ 1
  592. and responds with a multilink frame with C\ =\ 1.
  593. .RT
  594. .sp 2P
  595. .LP
  596. 2.5.4.3
  597.     \fITransmitting\fR 
  598. \fImultilink frames\fR 
  599. .sp 1P
  600. .RT
  601. .sp 1P
  602. .LP
  603. 2.5.4.3.1
  604.     \fIGeneral\fR 
  605. .sp 9p
  606. .RT
  607. .PP
  608. The transmitting DCE or DTE MLP shall be responsible for
  609. controlling the flow of packets from the Packet Layer into multilink frames 
  610. and then to the SLPs for transmission to the receiving DTE or DCE\ MLP, 
  611. respectively.
  612. .PP
  613. The functions of the transmitting DCE or DTE MLP shall be
  614. to:
  615. .RT
  616. .LP
  617.     a)
  618.     accept packets from the Packet Layer;
  619. .LP
  620.     b)
  621.     allocate multilink control fields, containing the
  622. appropriate sequence number MN(S), to the packets;
  623. .LP
  624.     c)
  625.     assure that MN(S) is not assigned outside the MLP transmit   window (MW);
  626. .LP
  627.     d)
  628.     pass the resultant multilink frames to the SLPs for
  629. transmission;
  630. .LP
  631.     e)
  632.     accept indications of successful transmission
  633. acknowledgements from the SLPs;
  634. .LP
  635.     f)
  636.     monitor and recover from transmission failures or
  637. difficulties that occur at the SLP sublayer; and
  638. .LP
  639.     g)
  640.     accept flow control indications from the SLPs and take
  641. appropriate actions.
  642. .sp 1P
  643. .LP
  644. 2.5.4.3.2
  645.     \fITransmission of multilink frames\fR 
  646. .sp 9p
  647. .RT
  648. .PP
  649. When the transmitting DCE MLP accepts a packet from the Packet
  650. Layer, it shall place the packet in a multilink frame, set the MN(S) equal 
  651. to MV(S), assure that MN(S) is not assigned outside the transmit window 
  652. (MW), set V, S, R and C to\ 0, and then increment MV(S) by\ 1. 
  653. .PP
  654. In the following, incrementing send and receive state variables is in reference 
  655. to a continuously repeated sequence series, i.e.\ 4095 is 1 higher 
  656. than\ 4094, and 0 is 1 higher than\ 4095 for modulo 4096\ series.
  657. .PP
  658. If the MN(S) is less than MV(T)\ +\ MW, and the DTE has not indicated a 
  659. busy condition on all available DCE SLPs, the transmitting DCE MLP may 
  660. then 
  661. assign the new multilink frame to an available DCE SLP. The transmitting DCE
  662. MLP shall always assign the lowest MN(S) unassigned multilink frame first.
  663. Also, the transmitting DCE MLP may assign a multilink frame to more than one
  664. DCE SLP. When the DCE SLP successfully completes the transmission of (a)
  665. multilink frame(s) by receiving an acknowledgement from the DTE SLP, it 
  666. shall indicate this to the transmitting DCE MLP. The transmitting DCE MLP 
  667. may then 
  668. discard the acknowledged multilink frame(s). As the transmitting DCE receives 
  669. new indications of acknowledgements from the DCE SLPs, MV(T) shall be advanced 
  670. to denote the lowest numbered multilink frame not yet acknowledged. 
  671. .PP
  672. Whenever a DCE SLP indicates that it has attempted to transmit a
  673. multilink frame N2 times, the DCE MLP will then assign the multilink frame 
  674. to the same or one or more other DCE SLPs unless the MN(S) has been acknowledged 
  675. on some previous DCE SLP. The DCE MLP shall always assign the lowest MN(S) 
  676. multilink frame first.
  677. .bp
  678. .PP
  679. \fINote\fR \ \(em\ If a DCE MLP implementation is such that a multilink 
  680. frame is assigned to more than one DCE SLP (e.g.\ to increase the probability 
  681. of 
  682. successful delivery) there is a possibility that one of these multilink 
  683. frames (i.e.\ a duplicate) may be delivered to the remote DTE MLP after 
  684. an earlier one has been acknowledged [the earlier multilink frame would 
  685. have resulted in the receiving DTE MLP having incremented its MV(R) and 
  686. the transmitting DCE MLP 
  687. having incremented its MV(T)]. To ensure that an old duplicate multilink 
  688. frame is not mistaken for a new frame by the receiving DTE MLP, it is required 
  689. that the transmitting DCE MLP shall never assign to a DCE SLP a new multilink 
  690. frame with MN(S) equal to MN(S)`\ \(em\ MW\ \(em\ MX, where MN(S)` is associated 
  691. with a 
  692. duplicate multilink frame that was earlier assigned to other DCE SLPs,
  693. until all DCE SLPs have either successfully transmitted the multilink frame
  694. MN(S)` or have attempted the transmission the maximum number of times.
  695. Alternatively, the incrementing of MV(T) may be withheld until all DCE SLPs
  696. that were assigned the multilink frame MN(S)` have either successfully
  697. transferred the multilink frame MN(S)` or have attempted the transmission
  698. the maximum number of times. These and other alternatives are for further
  699. study.
  700. .PP
  701. Flow control is achieved by the window size parameter MW, and through busy 
  702. conditions being indicated by the DTE SLPs. 
  703. .PP
  704. The DCE MLP will not assign a multilink frame with an MN(S) greater
  705. than MV(T) + MW\ \(em\ 1. At the point where the next DCE multilink frame to be
  706. assigned has an MN(S) = MV(T) + MW, the DCE MLP shall hold this and
  707. subsequent multilink frames until an indication of an acknowledgement that
  708. advances MV(T) is received from the DCE SLPs.
  709. .PP
  710. The DTE MLP may exercise flow control of the DCE MLP by indicating a busy 
  711. condition over one or more DTE SLPs. The number of SLPs made busy will 
  712. determine the degree of DCE MLP flow control realized. When the DCE MLP
  713. receives an indication of a DTE SLP busy condition from one or more of 
  714. its DCE SLPs, the DCE MLP may reassign any unacknowledged multilink frames 
  715. that were 
  716. assigned to those DCE SLPs. The DCE MLP will assign the multilink frames
  717. containing the lowest MN(S) to an available DCE SLP as specified
  718. above.
  719. .PP
  720. \fINote\ 1\fR \ \(em\ The action to be taken on the receipt of an RNR frame by
  721. the DCE SLP whose unac
  722. knowledged\ multilink frames have been reassigned is
  723. for further study.
  724. .PP
  725. In the event of a circuit failure, a DCE SLP reset, or a DCE SLP or
  726. DTE SLP disconnection, all DCE MLP multilink frames that were unacknowledged 
  727. on the affected DCE SLPs shall be reassigned to an operational DCE SLP(s) 
  728. which 
  729. is(are) not in the busy condition.
  730. .PP
  731. \fINote\ 2\fR \ \(em\ The means of detecting transmitting DCE MLP malfunctions
  732. (e.g.\ sending more than MW multilink frames) and the actions to be taken are
  733. for further study.
  734. .RT
  735. .sp 1P
  736. .LP
  737. 2.5.4.4
  738.     \fIReceiving multilink frames\fR 
  739. .sp 9p
  740. .RT
  741. .PP
  742. Any multilink frame less than two octets in length shall be
  743. discarded by the receiving DCE MLP.
  744. .PP
  745. \fINote\fR \ \(em\ The procedures to be followed by the receiving DCE MLP 
  746. when V and/or S is equal to 1 are for further study. The procedures to 
  747. be followed by the receiving DCE MLP when R or C is equal to 1 are described 
  748. in \(sc\ 2.5.4.2 
  749. above.
  750. .PP
  751. When the DCE MLP receives multilink frames from one of the DCE SLPs, the 
  752. DCE MLP will compare the multilink sequence number MN(S) of the received 
  753. multilink frame to its multilink receive state variable MV(R), and act 
  754. on the multilink frame as follows: 
  755. .RT
  756. .LP
  757.     a)
  758.     If the received MN(S) is equal to the current value of
  759. MV(R), i.e.\ is the next expected in\(hysequence multilink frame,
  760. the DCE MLP delivers the packet to the Packet Layer.
  761. .LP
  762.     b)
  763.     If the MN(S) is greater than the current value of MV(R) but
  764. less than MV(R) + MW + MX, the DCE MLP keeps the received
  765. multilink frame until condition a) is met, or discards it if it
  766. is a duplicate.
  767. .LP
  768.     c)
  769.     If the MN(S) is other than in a) and b) above, the multilink
  770. frame is discarded.
  771. .PP
  772. \fINote\fR \ \(em\ In case c) above, the recovery from desynchronization
  773. greater than MX between the local and the remote MLP, i.e.,\ the value 
  774. of MN(S) reassigned to new multilink frames at the remote MLP is higher 
  775. than 
  776. MV(R)\ +\ MW\ +\ MX at the local MLP, is for further study.
  777. .bp
  778. .PP
  779. On receipt of each multilink frame, MV(R) is incremented by the
  780. DCE\ MLP in the following way:
  781. .RT
  782. .LP
  783.     i)
  784.     If MN(S) is equal to the current value of MV(R), the MV(R)
  785. is incremented by the number of consecutive in\(hysequence
  786. multilink frames that have been received. If additional
  787. multilink frames are awaiting delivery pending receipt of a
  788. multilink frame with MN(S) equal to the updated MV(R), then
  789. Timer MT1 (see \(sc\ 2.5.5.1 below) is restarted; otherwise Timer
  790. MT1 is stopped.
  791. .LP
  792.     ii)
  793.     If MN(S) is greater than the current value of MV(R) but
  794. less than MV(R) + MW, MV(R) remains unchanged. Timer\ MT1 is
  795. started, if not already running.
  796. .LP
  797.     iii)
  798.     If MN(S) is \(>=" MV(R) + MW but < MV(R) + MW + MX, MV(R) is
  799. incremented to MN(S) \(em MW + 1 and then the Packet Layer may
  800. be informed of the packet loss at the original value of MV(R).
  801. As MV(R) is being incremented, if any multilink frame with
  802. MN(S) =\ MV(R) has not yet been received, the Packet Layer may be
  803. informed of that packet loss also; if the multilink frame with
  804. MN(S)\ =\ MV(R) has been received, it is delivered to the Packet
  805. Layer. After MV(R) reaches MN(S) \(em MW\ +\ 1, it will then be
  806. incremented further (as in i) above) until the first
  807. unacknowledged MN(S) is encountered. See Figure\ 3/X.25.
  808. .LP
  809.     iv)
  810.     If the MN(S) is other than that in i), ii) and iii) above,
  811. MV(R) remains unchanged.
  812. .LP
  813. .rs
  814. .sp 23P
  815. .ad r
  816. \fBFigure 3/X.25, p.\fR 
  817. .sp 1P
  818. .RT
  819. .ad b
  820. .RT
  821. .PP
  822. If Timer MT1 runs out, MV(R) is incremented to the MN(S) of the
  823. next multilink frame awaiting delivery to the Packet Layer and then the 
  824. Packet Layer may be informed of the packet loss at the original MV(R). 
  825. The procedure follows\ a) and\ i) above as long as there are consecutive 
  826. in\(hysequence multilink frames which have been received. 
  827. .PP
  828. When flow control of the DTE MLP is desired, one or more DCE
  829. SLP(s) may be made to indicate a busy condition. The number of DCE SLPs made
  830. busy determines the degree of flow control realized.
  831. .bp
  832. .PP
  833. If the DCE MLP can exhaust its receive buffer capacity before
  834. resequencing can be completed, Timer MT2 (see \(sc\ 2.5.5.2 below) may be
  835. implemented. Whenever a busy condition is indicated by the DCE MLP on all 
  836. DCE SLPs, and multilink frames at the DCE MLP are awaiting resequencing, 
  837. Timer\ MT2 shall be started. When the busy condition is cleared on one 
  838. or more DCE SLPs by the DCE MLP, Timer MT2 shall be stopped. 
  839. .PP
  840. If Timer MT2 runs out, the multilink frame with MN(S) = MV(R) is
  841. blocked and shall be considered lost. MV(R) shall be incremented to the next
  842. sequence number not yet received, and the packets contained in multilink
  843. frames with intervening multilink sequence numbers are delivered to the 
  844. Packet Layer. Timer MT2 shall be restarted if the busy condition remains 
  845. in effect on all DCE SLPs and more multilink frames are awaiting resequencing. 
  846. .RT
  847. .sp 1P
  848. .LP
  849. 2.5.4.5
  850.     \fITaking an SLP out of service\fR 
  851. .sp 9p
  852. .RT
  853. .PP
  854. A DCE SLP may be taken out of service for maintenance, traffic, or performance 
  855. considerations. 
  856. .PP
  857. A DCE SLP is taken out of service by disconnecting at the Physical
  858. Layer or the Data Link Layer. Any outstanding DCE MLP multilink frames 
  859. will be reassigned to one or more other DCE SLPs, unless the MN(S) has 
  860. been previously acknowledged on some other DCE SLP. The usual procedure 
  861. for taking a DCE SLP 
  862. out of service at the Data Link Layer would be to flow control the DTE 
  863. SLP with an RNR frame, and then logically disconnect the DCE\ SLP 
  864. (see \(sc\ 2.4.4.3 above).
  865. .PP
  866. If the DCE SLP Timer T1 has run out N2 times and the DCE SLP data link 
  867. resetting procedure is unsuccessful, then the DCE SLP will enter the 
  868. disconnected phase, taking the DCE SLP out of service (see \(sc\(sc\ 2.4.5.8
  869. and\ 2.4.7.2 above).
  870. .PP
  871. \fINote\fR \ \(em\ In the case where all SLPs are out of service, the recovery 
  872. mechanism is based on initiating the multilink resetting procedures. Other 
  873. recovery procedures are for further study.
  874. .RT
  875. .sp 2P
  876. .LP
  877. 2.5.5
  878.     \fIList of \fR \fImultilink system parameters\fR 
  879. .sp 1P
  880. .RT
  881. .sp 1P
  882. .LP
  883. 2.5.5.1
  884.     \fILost\(hyframe Timer MT1 (multilink)\fR 
  885. .sp 9p
  886. .RT
  887. .PP
  888. Timer MT1 is used at a receiving DCE MLP to provide a means to
  889. identify during low traffic periods that the multilink frame with MN(S) 
  890. equal to MV(R) is lost. 
  891. .RT
  892. .sp 1P
  893. .LP
  894. 2.5.5.2
  895.     \fIGroup busy Timer MT2 (multilink)\fR 
  896. .sp 9p
  897. .RT
  898. .PP
  899. Timer MT2 is provided at a receiving DCE MLP to identify a
  900. \*Qblocked\*U multilink frame condition (e.g.\ a buffer exhaust situation) that
  901. occurs before required resequencing can be accomplished. Timer MT2 is started 
  902. when all DCE SLPs are busy and there are multilink frames awaiting 
  903. resequencing. If Timer MT2 runs out before the \*Qblocked\*U multilink 
  904. frame MV(R) is received, the \*Qblocked\*U multilink frame(s) is(are) declared 
  905. lost. MV(R) is incremented to the value of the next in\(hysequence multilink 
  906. frame to be 
  907. received, and any packets in intervening multilink frames are delivered 
  908. to the Packet Layer. 
  909. .PP
  910. \fINote\fR \ \(em\ Timer MT2 may be set to infinity; e.g.\ when the receiving
  911. DCE always has sufficient storage capacity.
  912. .RT
  913. .sp 1P
  914. .LP
  915. 2.5.5.3
  916.     \fIMLP reset confirmation Timer MT3 (multilink)\fR 
  917. .sp 9p
  918. .RT
  919. .PP
  920. Timer MT3 is used by the DCE MLP to provide a means of identifying that 
  921. the DTE MLP multilink frame with the C bit set to\ 1 that is expected 
  922. following the transmission of the DCE MLP multilink frame with R bit set 
  923. to\ 1, has not been received. 
  924. .RT
  925. .sp 2P
  926. .LP
  927. 2.6
  928.     \fILAP elements of procedure\fR 
  929. .sp 1P
  930. .RT
  931. .PP
  932. 2.6.1
  933. The LAP elements of procedure are defined in terms of actions that occur 
  934. on receipt of frames at the DCE or DTE. 
  935. .bp
  936. .sp 9p
  937. .RT
  938. .PP
  939. The elements of procedure specified below contain the selection of commands 
  940. and responses relevant to the LAP data link and system configurations described 
  941. in \(sc\ 2.1\ above. Together, \(sc\(sc\ 2.2 and\ 2.6 form the general 
  942. requirements for the proper management of a LAP access data link.
  943. .sp 2P
  944. .LP
  945. 2.6.2
  946.     \fILAP control field formats and parameters\fR 
  947. .sp 1P
  948. .RT
  949. .sp 1P
  950. .LP
  951. 2.6.2.1
  952.     \fIControl field formats\fR 
  953. .sp 9p
  954. .RT
  955. .PP
  956. The control field contains a command or a response, and sequence
  957. numbers where applicable.
  958. .PP
  959. Three types of control field formats (see Table\ 11/X.25) are used to perform 
  960. numbered information transfer (I\ format), numbered supervisory 
  961. functions (S\ format) and unnumbered control functions (U\ format).
  962. .RT
  963. .LP
  964. .sp 1
  965. .ce
  966. \fBH.T. [T9.25]\fR 
  967. .ce
  968. TABLE\ 11/X.25
  969. .ce
  970. \fBLAP control field formats (modulo 8)\fR 
  971. .ps 9
  972. .vs 11
  973. .nr VS 11
  974. .nr PS 9
  975. .TS
  976. center box;
  977. cw(36p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) .
  978. Control field bits    1    2    3    4    5    6    7    8
  979. _
  980. .T&
  981. lw(36p) | cw(24p) | cw(72p) | cw(24p) | cw(72p) .
  982. I format    0    N(S)    P    N(R)
  983. _
  984. .T&
  985. lw(36p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(72p) .
  986. S format    1    0    S    S    P/F    N(R)
  987. _
  988. .T&
  989. lw(36p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) .
  990. U format    1    1    M    M    P/F    M    M    T{
  991. M
  992. N(S)
  993. Transmitter send sequence number (bit 2\|=\|low\(hyorder bit)
  994. .parag
  995. N(R)
  996. Transmitter receive sequence number (bit 6\|=\|low\(hyorder bit)
  997. .parag
  998. S
  999. Supervisory function bit
  1000. .parag
  1001. M
  1002. Modifier function bit
  1003. .parag
  1004. P/F
  1005. Poll bit when issued as a command, final bit when issued as a
  1006. response. (1\|=\|Poll/Final)
  1007. .parag
  1008. P
  1009. Poll bit (1\|=\|Poll)
  1010. .parag
  1011. T}
  1012. _
  1013. .TE
  1014. .nr PS 9
  1015. .RT
  1016. .ad r
  1017. \fBTable 11/X.25 [T9.25], p.\fR 
  1018. .sp 1P
  1019. .RT
  1020. .ad b
  1021. .RT
  1022. .LP
  1023. .sp 1
  1024. .sp 1P
  1025. .LP
  1026. 2.6.2.1.1
  1027.     \fIInformation transfer format\ \(em\ I\fR 
  1028. .sp 9p
  1029. .RT
  1030. .PP
  1031. The I format is used to perform an information transfer. The
  1032. functions of N(S), N(R) and P are independent, i.e.\ each I\ frame has 
  1033. an N(S), an N(R) which may or may not acknowledge additional I\ frames 
  1034. received by the 
  1035. DCE or DTE, and a P\ bit that may be set to\ 0 or\ 1.
  1036. .RT
  1037. .sp 1P
  1038. .LP
  1039. 2.6.2.1.2
  1040.     \fISupervisory format\ \(em\ S\fR 
  1041. .sp 9p
  1042. .RT
  1043. .PP
  1044. The S format is used to perform data link supervisory control
  1045. functions such as acknowledge I frames, request retransmission of I frames, 
  1046. and to request a temporary suspension of transmission of I\ frames. The 
  1047. functions 
  1048. of N(R) and P/F are independent, i.e.\ each supervisory frame has an N(R) 
  1049. which may or may not acknowledge additional I\ frames received by the DCE 
  1050. or DTE, and a P/F bit that may be set to 0 or\ 1. 
  1051. .bp
  1052. .RT
  1053. .sp 1P
  1054. .LP
  1055. 2.6.2.1.3
  1056.     \fIUnnumbered format\ \(em\ U\fR 
  1057. .sp 9p
  1058. .RT
  1059. .PP
  1060. The U format is used to provide additional data link control
  1061. functions. This format contains no sequence numbers, but does include a 
  1062. P/F bit that may be set to\ 0 or\ 1. 
  1063. .RT
  1064. .sp 1P
  1065. .LP
  1066. 2.6.2.2
  1067.     \fIControl field parameters\fR 
  1068. .sp 9p
  1069. .RT
  1070. .PP
  1071. The various parameters associated with the control field formats
  1072. are described below.
  1073. .RT
  1074. .sp 1P
  1075. .LP
  1076. 2.6.2.2.1
  1077.     \fIModulus\fR 
  1078. .sp 9p
  1079. .RT
  1080. .PP
  1081. Each I frame is sequentially numbered and may have the value\ 0
  1082. through modulus minus 1 (where \*Qmodulus\*U is the modulus of the sequence
  1083. numbers). The modulus equals\ 8 and the sequence numbers cycle through the
  1084. entire range.
  1085. .RT
  1086. .sp 1P
  1087. .LP
  1088. 2.6.2.2.2
  1089.     \fISend state variable V(S)\fR 
  1090. .sp 9p
  1091. .RT
  1092. .PP
  1093. The send state variable V(S) denotes the sequence number of the
  1094. next in\(hysequence I\ frame to be transmitted. V(S) can take on the value\ 0
  1095. through modulus minus\ 1. The value of V(S) is incremented by\ 1 with each
  1096. successive I\ frame transmission, but cannot exceed N(R) of the last received\ 
  1097. I or supervisory frame by more than the maximum number of outstanding I\ 
  1098. frames 
  1099. (k).  The value of k is defined in \(sc\ 2.7.7.6 below.
  1100. .RT
  1101. .sp 1P
  1102. .LP
  1103. 2.6.2.2.3
  1104.     \fISend sequence number N(S)\fR 
  1105. .sp 9p
  1106. .RT
  1107. .PP
  1108. Only I frames contain N(S), the send sequence number of transmitted I\ 
  1109. frames. At the time that an in\(hysequence I\ frame is designated for 
  1110. transmission, the value of N(S) is set equal to the value of the send state
  1111. variable\ V(S).
  1112. .RT
  1113. .sp 1P
  1114. .LP
  1115. 2.6.2.2.4
  1116.     \fIReceive state variable V(R)\fR 
  1117. .sp 9p
  1118. .RT
  1119. .PP
  1120. The receive state variable V(R) denotes the sequence number of the next 
  1121. in\(hysequence I\ frame expected to be received. V(R) can take on the values\ 
  1122. 0 through modulus minus\ 1. The value of V(R) is incremented by\ 1 with 
  1123. the receipt of an error free, in\(hysequence I\ frame whose send sequence 
  1124. number N(S) equals 
  1125. the receive state variable V(R).
  1126. .RT
  1127. .sp 1P
  1128. .LP
  1129. 2.6.2.2.5
  1130.     \fIReceive sequence number N(R)\fR 
  1131. .sp 9p
  1132. .RT
  1133. .PP
  1134. All I frames and supervisory frames contain N(R), the expected send sequence 
  1135. number of the next received I\ frame. At the time that a frame of the above 
  1136. types is designed for transmission, the value of N(R) is set equal to the 
  1137. current value of the receive state variable V(R). N(R) indicates that the 
  1138. DCE or DTE transmitting the N(R) has received correctly all I\ frames numbered 
  1139. up to and including N(R)\ \(em\ 1. 
  1140. .RT
  1141. .sp 1P
  1142. .LP
  1143. 2.6.2.2.6
  1144.     \fIPoll/Final bit P/F\fR 
  1145. .sp 9p
  1146. .RT
  1147. .PP
  1148. All frames contain P/F, the Poll/Final bit. In command frames the P/F bit 
  1149. is referred to as the P\ bit. In response frames it is referred to as 
  1150. the F\ bit.
  1151. .RT
  1152. .sp 1P
  1153. .LP
  1154. 2.6.3
  1155.     \fIFunctions of the \fR \fIPoll/Final bit\fR 
  1156. .sp 9p
  1157. .RT
  1158. .PP
  1159. The Poll bit set to 1 is used by the DCE or DTE to solicit (poll) a response 
  1160. from the DTE or DCE, respectively. The Final bit set to\ 1 is used by the 
  1161. DCE or DTE to indicate the response frame transmitted by the DTE or DCE, 
  1162. respectively, as a result of the soliciting (poll) command.
  1163. .PP
  1164. The use of the P/F bit is described in \(sc\ 2.7.2 below.
  1165. .RT
  1166. .sp 1P
  1167. .LP
  1168. 2.6.4
  1169.     \fICommands and responses\fR 
  1170. .sp 9p
  1171. .RT
  1172. .PP
  1173. The commands and responses represented in Table\ 12/X.25 will be
  1174. supported by the DCE and the DTE.
  1175. .RT
  1176. .PP
  1177. For purposes of the LAP procedures, the supervisory function bit encoding 
  1178. \*Q11\*U and those encodings of the modifier function bits in 
  1179. Table\ 11/X.25 not identified in Table\ 12/X.25 are identified as \*Qundefined 
  1180. or not implemented\*U command and response control fields. 
  1181. .bp
  1182. .RT
  1183. .ce
  1184. \fBH.T. [T10.25]\fR 
  1185. .ce
  1186. TABLE\ 12/X.25
  1187. .ce
  1188. \fBLAP commands and responses\fR 
  1189. .ps 9
  1190. .vs 11
  1191. .nr VS 11
  1192. .nr PS 9
  1193. .TS
  1194. center box;
  1195. lw(126p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(18p) | cw(12p) | cw(12p) | cw(12p) .
  1196.     1    2    3    4    5    6    7    8
  1197. .T&
  1198. cw(36p) | cw(48p) | cw(42p) | cw(102p) .
  1199. Format    Command    Response    Encoding
  1200. _
  1201. .T&
  1202. lw(36p) | lw(18p) | lw(30p) | lw(42p) | cw(12p) | cw(36p) | cw(18p) | cw(36p) .
  1203. Information transfer    I    (information)        0    N(S)    P    N(R)
  1204. _
  1205. .T&
  1206. lw(36p) | lw(18p) | lw(30p) | lw(18p) | lw(24p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(18p) | cw(36p) .
  1207. Supervisory    RR    (receive ready)    RR    (receive ready)    1    0    0    0    P/F    N(R)
  1208. .T&
  1209. lw(36p) | lw(18p) | lw(30p) | lw(18p) | lw(24p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(18p) | cw(36p) .
  1210.     RNR    (receive not ready)    RNR    (receive not ready)    1    0    1    0    P/F    N(R)
  1211. .T&
  1212. lw(36p) | lw(18p) | lw(30p) | lw(18p) | lw(24p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(18p) | cw(36p) .
  1213.     REJ    (reject)    REJ    (reject)    1    0    0    1    P/F    N(R)
  1214. _
  1215. .T&
  1216. lw(36p) | lw(18p) | lw(30p) | lw(42p) | lw(12p) | lw(12p) | lw(12p) | lw(12p) | lw(18p) | lw(12p) | lw(12p) | lw(12p) .
  1217. 1 1 1 1 P 0 0 0                                            
  1218. .T&
  1219. lw(36p) | lw(18p) | lw(30p) | lw(42p) | lw(12p) | lw(12p) | lw(12p) | lw(12p) | lw(18p) | lw(12p) | lw(12p) | lw(12p) .
  1220. DISC (disconnect)    1 1 0 0 P 0 1 0                                        
  1221. _
  1222. .T&
  1223. lw(84p) | lw(18p) | lw(24p) | lw(12p) | lw(12p) | lw(12p) | lw(12p) | lw(18p) | lw(12p) | lw(12p) | lw(12p) .
  1224. T{
  1225. CMDR
  1226. (command reject)
  1227. 1
  1228. 1
  1229. 1
  1230. 0
  1231. F
  1232. 0
  1233. 0
  1234. 1
  1235. T}                                        
  1236. _
  1237. .T&
  1238. lw(84p) | lw(18p) | lw(24p) | lw(12p) | lw(12p) | lw(12p) | lw(12p) | lw(18p) | lw(12p) | lw(12p) | lw(12p) .
  1239. T{
  1240. UA
  1241. (unnumbered acknowledge
  1242. ment)
  1243. 1
  1244. 1
  1245. 0
  1246. 0
  1247. F
  1248. 1
  1249. 1
  1250. 0
  1251. \fINote\fR
  1252. \ \(em\ RR, RNR and REJ supervisory commands are transmitted by the DCE.
  1253. .parag
  1254. T}                                        
  1255. _
  1256. .TE
  1257. .nr PS 9
  1258. .RT
  1259. .ad r
  1260. \fBTable 12/X.25 [T10.25], p.\fR 
  1261. .sp 1P
  1262. .RT
  1263. .ad b
  1264. .RT
  1265. .PP
  1266. The commands and responses in Table\ 12/X.25 are defined as
  1267. follows:
  1268. .RT
  1269. .sp 1P
  1270. .LP
  1271. 2.6.4.1
  1272.     \fIInformation (I)  command\fR 
  1273. .sp 9p
  1274. .RT
  1275. .PP
  1276. The function of the information (I) command is to transfer across a data 
  1277. link a sequentially numbered frame containing an information 
  1278. field.
  1279. .RT
  1280. .sp 1P
  1281. .LP
  1282. 2.6.4.2
  1283.     \fIReceive ready (RR) command and response\fR 
  1284. .sp 9p
  1285. .RT
  1286. .PP
  1287. The receive ready (RR) supervisory frame is used by the DCE or DTE  to:
  1288. .RT
  1289. .LP
  1290.     1)
  1291.     indicate it is ready to receive an I frame; and
  1292. .LP
  1293.     2)
  1294.     acknowledge previously received I frames numbered up to and
  1295. including N(R)\ \(em\ 1.
  1296. .PP
  1297. An RR frame may be used to indicate the clearance of a busy
  1298. condition that was reported by the earlier transmission of an RNR frame 
  1299. by that same station (DCE or DTE). The RR command with the P bit set to\ 
  1300. 1 may be used by the DTE to ask for the status of the DCE. 
  1301. .sp 1P
  1302. .LP
  1303. 2.6.4.3
  1304.     \fIReject (REJ) command and response\fR 
  1305. .sp 9p
  1306. .RT
  1307. .PP
  1308. The reject (REJ) supervisory frame is used by the DCE or DTE to
  1309. request transmission of I\ frames starting with the frame numbered N(R).
  1310. I\ frames numbered N(R)\ \(em\ 1 and below are acknowledged. Additional 
  1311. I\ frames 
  1312. pending initial transmission may be transmitted following the retransmitted
  1313. I\ frame(s).
  1314. .bp
  1315. .PP
  1316. For a given direction of information transfer, only one REJ exception condition 
  1317. may be established at any time. The REJ exception condition is 
  1318. cleared (reset) upon the receipt of an I\ frame with an N(S) equal to the 
  1319. N(R) of the REJ\ frame. 
  1320. .PP
  1321. An REJ frame may be used to indicate the clearance of a busy condition 
  1322. that was reported by the earlier transmission of an RNR frame by that same 
  1323. station (DCE or DTE). The REJ command with the P\ bit set to\ 1 may be used by
  1324. the DTE to ask for the status of the DCE.
  1325. .RT
  1326. .sp 1P
  1327. .LP
  1328. 2.6.4.4
  1329.     \fIReceive not ready (RNR) command and response\fR 
  1330. .sp 9p
  1331. .RT
  1332. .PP
  1333. The receive not ready (RNR) supervisory frame is used by the DCE or DTE 
  1334. to indicate a busy condition, i.e.\ temporary inability to accept 
  1335. additional incoming I\ frames. I\ frames numbered up to and including N(R)\ 
  1336. \(em\ 1 
  1337. are acknowledged. I\ frame N(R) and any subsequent I\ frames received, if any,
  1338. are not acknowledged; the acceptance status of these I\ frames will be 
  1339. indicated in subsequent exchanges. 
  1340. .PP
  1341. The RNR command with the P bit set to 1 may be used by the DTE to ask for 
  1342. the status of the DCE. 
  1343. .RT
  1344. .sp 1P
  1345. .LP
  1346. 2.6.4.5
  1347.     \fISet asynchronous response mode (SARM) command\fR 
  1348. .sp 9p
  1349. .RT
  1350. .PP
  1351. The SARM unnumbered command is used to place the addressed DCE or DTE in 
  1352. the asynchronous response mode (ARM) information transfer phase, where 
  1353. all command/response control fields will be one octet in length. 
  1354. .PP
  1355. No information field is permitted with the SARM command. A DCE or DTE confirms 
  1356. acceptance of an SARM command by the transmission at the first 
  1357. opportunity of a UA response. Upon acceptance of this command, the DCE 
  1358. or DTE receive state variable V(R) is set to\ 0. 
  1359. .PP
  1360. Previously transmitted I frames that are unacknowledged when this
  1361. command is actioned remain unacknowledged. It is the responsibility of 
  1362. a higher layer (e.g.\ Packet Layer) to recover from the possible loss of 
  1363. the contents 
  1364. (packets) of such I\ frames.
  1365. .RT
  1366. .sp 1P
  1367. .LP
  1368. 2.6.4.6
  1369.     \fIDisconnect (DISC) command\fR 
  1370. .sp 9p
  1371. .RT
  1372. .PP
  1373. The DISC unnumbered command is used to terminate the mode
  1374. previously set. It is used to inform the DCE or DTE receiving the DISC 
  1375. that the DTE or DCE sending the DISC command is suspending operation. No 
  1376. information 
  1377. field is permitted with the DISC command. Prior to actioning the DISC command, 
  1378. the DCE or DTE receiving the DISC command confirms the acceptance of the 
  1379. DISC command by the transmission of a UA response. The DTE or DCE sending 
  1380. the DISC command enters the disconnected phase when it receives the acknowledging 
  1381. UA 
  1382. response.
  1383. .PP
  1384. Previously transmitted I frames that are unacknowledged when this
  1385. command is actioned remain unacknowledged. It is the responsibility of 
  1386. a higher layer (e.g.\ Packet Layer) to recover from the possible loss of 
  1387. the contents 
  1388. (packets) of such I\ frames.
  1389. .RT
  1390. .sp 1P
  1391. .LP
  1392. 2.6.4.7
  1393.     \fIUnnumbered acknowledgement (UA) response\fR 
  1394. .sp 9p
  1395. .RT
  1396. .PP
  1397. The UA unnumbered response is used by the DCE or DTE to acknowledge the 
  1398. receipt and acceptance of the mode\(hysetting commands. Received mode\(hysetting 
  1399. commands are not actioned until the UA response is transmitted. The UA 
  1400. response is transmitted as directed by the received U\ format command. 
  1401. No information 
  1402. field is permitted with the UA response.
  1403. .RT
  1404. .sp 1P
  1405. .LP
  1406. 2.6.4.8
  1407.     \fICommand reject (CMDR) response\fR 
  1408. .sp 9p
  1409. .RT
  1410. .PP
  1411. The CMDR unnumbered response is used by the DCE or DTE to report an error 
  1412. condition not recoverable by retransmission of the identical frame, 
  1413. i.e.\ at least one of the following conditions, which results from the 
  1414. receipt of a valid command frame: 
  1415. .RT
  1416. .LP
  1417.     1)
  1418.     the receipt of a command control field that is undefined or
  1419. not implemented;
  1420. .LP
  1421.     2)
  1422.     the receipt of an I frame with an information field which
  1423. exceeds the maximum established length;
  1424. .LP
  1425.     3)
  1426.     the receipt of an invalid N(R) (see \(sc\ 2.7.5.1), or
  1427. .LP
  1428.     4)
  1429.     the receipt of a frame with an information field which is
  1430. not permitted or the receipt of a supervisory or unnumbered
  1431. frame with incorrect length.
  1432. .bp
  1433. .PP
  1434. An undefined or not implemented control field is any of the
  1435. control field encodings that are not identified in Table\ 12/X.25.
  1436. .PP
  1437. An invalid N(R) is defined as one which points to an I frame which has 
  1438. previously been transmitted and acknowledged or to an I\ frame which has 
  1439. not 
  1440. been transmitted and is not the next sequential I\ frame awaiting transmission.
  1441. .PP
  1442. An information field which immediately follows the control field, and consists 
  1443. of 3\ octets, is returned with this response and provides the reason 
  1444. for the CMDR response. This format is given in Table\ 13/X.25.
  1445. .RT
  1446. .LP
  1447. .sp 1
  1448. .ce
  1449. \fBH.T. [T11.25]\fR 
  1450. .ce
  1451. TABLEAU\ 13/X.25
  1452. .ce
  1453. \fBLAP CMDR information field format\fR 
  1454. .ce
  1455. Information field bits
  1456. .ps 9
  1457. .vs 11
  1458. .nr VS 11
  1459. .nr PS 9
  1460. .TS
  1461. center box;
  1462. cw(42p) | cw(12p) | cw(30p) | cw(18p) | cw(30p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) .
  1463. T{
  1464. 1\ \|2\ \|3\ \|4\ \|5\ \|6\ \|7\ \|8 \fR
  1465. T}    9    10\ \|11\ \|12    13    14\ 15\ 16    17    18    19    20    21    22    23    24
  1466. _
  1467. .T&
  1468. lw(42p) | cw(12p) | cw(30p) | cw(18p) | cw(30p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) .
  1469. T{
  1470. Rejected command control field
  1471. T}    0    V(S)    0    V(R)    W    X    Y    Z    0    0    0    T{
  1472. 0
  1473. \(em
  1474. Rejected command control field is the control field of the received
  1475. command which caused the command reject.
  1476. .parag
  1477. \(em
  1478. V(S) is the current send state variable value at the DCE or DTE reporting the rejection condition (bit 10\|=\|low\(hyorder bit).
  1479. .parag
  1480. \(em
  1481. V(R) is the current receive state variable value at the DCE or DTE
  1482. reporting the rejection condition (bit 14\|=\|low\(hyorder bit).
  1483. .parag
  1484. \(em
  1485. W set to 1 indicates that the control field received and returned in bits 1 through 8 was undefined or not implemented.
  1486. .parag
  1487. \(em
  1488. X set to 1 indicates that the control field received and returned in bits 1 through 8 was considered invalid because the frame contained an information field which is not permitted with this frame or is a supervisory or unnumbered frame with an incorrect length. Bit W must be set to 1 conjunction with this
  1489. bit.
  1490. .parag
  1491. \(em
  1492. Y set to 1 indicates that the information field received exceeded the
  1493. maximum established capacity of the DCE or DTE reporting the rejection
  1494. condition.
  1495. .parag
  1496. \(em
  1497. Z set to 1 indicates the control field received and returned in bits 1
  1498. through 8 contained an invalid N(R).
  1499. .parag
  1500. \fINote\fR
  1501. \ \(em\ Bits 9, 13 and 21 to 24 shall be set to 0.
  1502. .parag
  1503. T}
  1504. _
  1505. .TE
  1506. .nr PS 9
  1507. .RT
  1508. .ad r
  1509. \fBTable 13/X.25 [T11.25], p. 
  1510. .sp 1P
  1511. .RT
  1512. .ad b
  1513. .RT
  1514. .LP
  1515. .sp 1
  1516. .sp 1P
  1517. .LP
  1518. 2.6.5
  1519.     \fIException condition reporting and recovery\fR 
  1520. .sp 9p
  1521. .RT
  1522. .PP
  1523. The error recovery procedures which are available to effect
  1524. recovery following the detection/occurrence of an exception condition at the
  1525. Data Link Layer are described below. Exception conditions described are 
  1526. those situations which may occur as the result of transmission errors, 
  1527. DCE or DTE 
  1528. malfunction, or operational situations.
  1529. .RT
  1530. .sp 1P
  1531. .LP
  1532. 2.6.5.1
  1533.     \fIBusy condition\fR 
  1534. .sp 9p
  1535. .RT
  1536. .PP
  1537. The busy condition results when the DCE or DTE is temporarily
  1538. unable to continue to receive I\ frames due to internal constraints,
  1539. e.g.\ receive buffering limitations. In this case an RNR frame is transmitted
  1540. from the busy DCE or DTE. I\ frames pending transmission may be transmitted 
  1541. from the busy DCE or DTE prior to or following the RNR frame. 
  1542. .PP
  1543. An indication that the busy condition has cleared is communicated by the 
  1544. transmission of a UA (only in response to a SARM command), RR, REJ or SARM 
  1545. frame. 
  1546. .bp
  1547. .RT
  1548. .LP
  1549. .sp 1P
  1550. .LP
  1551. 2.6.5.2
  1552.     \fIN(S) sequence error condition\fR 
  1553. .sp 9p
  1554. .RT
  1555. .PP
  1556. The information field of all I frames received whose N(S) does not equal 
  1557. the receive state variable V(R) will be discarded. 
  1558. .PP
  1559. An N(S) sequence error exception condition occurs in the receiver when 
  1560. an I\ frame received contains an N(S) which is not equal to the receive 
  1561. state 
  1562. variable V(R) at the receiver. The receiver does not acknowledge (increment 
  1563. its receive state variable) the I\ frame causing the sequence error, or 
  1564. any I\ frames which may follow, until an I\ frame with the correct N(S) 
  1565. is received. 
  1566. .PP
  1567. A DCE or DTE which receives one or more valid I frames having sequence 
  1568. errors but otherwise errorless shall accept the control information contained 
  1569. in the N(R) field and the P\ bit to perform data link control functions, 
  1570. e.g.\ to receive acknowledgement of previously transmitted I\ frames and 
  1571. to cause the DCE or DTE to respond (P\ bit set to\ 1). Therefore, the retransmitted 
  1572. frame may 
  1573. contain an N(R) and a P\ bit that are updated from, and therefore different
  1574. from, those contained in the originally transmitted I\ frame.
  1575. .PP
  1576. The methods specified in \(sc\(sc\ 2.6.5.2.1 and\ 2.6.5.2.2 shall be available 
  1577. for initiating the retransmission of lost of errored I\ frames following 
  1578. the 
  1579. occurrence of an N(S) sequence error condition.
  1580. .RT
  1581. .sp 1P
  1582. .LP
  1583. 2.6.5.2.1
  1584.     \fIREJ recovery\fR 
  1585. .sp 9p
  1586. .RT
  1587. .PP
  1588. The REJ frame is used by a receiving DCE or DTE to initiate a
  1589. recovery (retransmission) following the detection of an N(S) sequence error.
  1590. .PP
  1591. With respect to each direction of transmission on the data link, only one 
  1592. \*Qsent REJ\*U exception condition from a DCE or DTE, to a DTE or DCE, 
  1593. is 
  1594. established at a time. A \*Qsent REJ\*U exception condition is cleared when the
  1595. requested I\ frame is received.
  1596. .PP
  1597. A DCE or DTE receiving an REJ frame initiates sequential
  1598. (re)transmission of I\ frames starting with the I frame indicated by the N(R)
  1599. obtained in the REJ frame.
  1600. .RT
  1601. .sp 1P
  1602. .LP
  1603. 2.6.5.2.2
  1604.     \fITime\(hyout recovery\fR 
  1605. .sp 9p
  1606. .RT
  1607. .PP
  1608. If a DCE or DTE, due to a transmission error, does not receive (or receives 
  1609. and discards) a single I\ frame or the last I\ frame(s) in a sequence of 
  1610. I\ frames, it will not detect an N(S) sequence error condition and, therefore, 
  1611. will not transmit an REJ frame. The DTE or DCE, which transmitted the 
  1612. unacknowledged I\ frame(s) shall, following the completion of a system 
  1613. specified time\(hyout period (see \(sc\(sc\ 2.7.4.8 and 2.7.7.1 below), 
  1614. take appropriate recovery action to determine at which I\ frame retransmission 
  1615. must begin. 
  1616. .RT
  1617. .sp 1P
  1618. .LP
  1619. 2.6.5.3
  1620.     \fIInvalid frame\fR \fIcondition\fR 
  1621. .sp 9p
  1622. .RT
  1623. .PP
  1624. Any frame which is invalid will be discarded, and no action will be taken 
  1625. as the result of that frame. An invalid frame is defined as one 
  1626. which:
  1627. .RT
  1628. .LP
  1629.     a)
  1630.     is not properly bounded by two flags;
  1631. .LP
  1632.     b)
  1633.     contains fewer than 32 bits between flags;
  1634. .LP
  1635.     c)
  1636.     contains a Frame Check Sequence (FCS) error; or
  1637. .LP
  1638.     d)
  1639.     contains an address other than A or B.
  1640. .PP
  1641. For those networks that are octet\(hyaligned, a detection of
  1642. non\(hyoctet alignment may be made at the Data Link Layer by adding a frame
  1643. validity check that requires the number of bits between the opening flag and
  1644. the closing flag, excluding bits inserted for transparency, to be an integral 
  1645. number of octets in length. Otherwise the frame is considered invalid. 
  1646. .sp 1P
  1647. .LP
  1648. 2.6.5.4
  1649.     \fICommand rejection\fR \fIcondition\fR 
  1650. .sp 9p
  1651. .RT
  1652. .PP
  1653. A command rejection condition is established upon the receipt of an error\(hyfree 
  1654. command frame with one of the conditions listed in \(sc\ 2.6.4.8 
  1655. above.
  1656. .PP
  1657. At the DCE or DTE, this command rejection exception condition is
  1658. reported by a CMDR response for appropriate DTE or DCE action, respectively.
  1659. Once a DCE has established such an exception condition, no additional I\ 
  1660. frames are accepted until the condition is reset by the DTE, except for 
  1661. examination 
  1662. of the P bit. The CMDR response may be repeated at each opportunity, as
  1663. specified in \(sc\ 2.7.6.5, until recovery is effected by the DTE, or until 
  1664. the DCE initiates its own recovery. 
  1665. .bp
  1666. .RT
  1667. .sp 1P
  1668. .LP
  1669. 2.6.5.5
  1670.     \fIExcessive idle channel state condition on the incoming channel\fR 
  1671. .sp 9p
  1672. .RT
  1673. .PP
  1674. Upon detection of an idle channel state condition (see \(sc\ 2.2.12.2 above) 
  1675. on the incoming channel, the DCE shall not take any action for a period 
  1676. T3 (see \(sc\ 2.7.7.3\ below), while waiting for detection of a return 
  1677. to the active channel state (i.e.\ detection of at least one flag sequence). 
  1678. After the period T3, the DCE shall notify the Packet Layer of the excessive 
  1679. idle channel state condition, but shall not take any action that would 
  1680. preclude the DTE from 
  1681. establishing the data link by normal data link set\(hyup procedures.
  1682. .PP
  1683. \fINote\fR \ \(em\ Other actions to be taken by the DCE at the Data Link 
  1684. Layer upon expiration of period T3 is a subject for further study. 
  1685. .RT
  1686. .sp 2P
  1687. .LP
  1688. 2.7
  1689.     \fIDescription of the LAP procedure\fR 
  1690. .sp 1P
  1691. .RT
  1692. .sp 1P
  1693. .LP
  1694. 2.7.1
  1695.     \fILAP procedure for addressing\fR 
  1696. .sp 9p
  1697. .RT
  1698. .PP
  1699. The address field identifies a frame as either a command or a
  1700. response. A command frame contains the address of the DCE or DTE to which 
  1701. the command is being sent. A response frame contains the address of the 
  1702. DCE or DTE sending the frame. 
  1703. .PP
  1704. Frames containing commands transferred from the DCE to the DTE
  1705. will contain the address\ A.
  1706. .PP
  1707. Frames containing responses transferred from the DCE to the DTE will contain 
  1708. the address\ B. 
  1709. .PP
  1710. Frames containing commands transferred from the DTE to the DCE shall contain 
  1711. the address\ B. 
  1712. .PP
  1713. Frames containing responses transferred from the DTE to the DCE shall contain 
  1714. the address\ A. 
  1715. .PP
  1716. A and B addresses are coded as follows:
  1717. .RT
  1718. .LP
  1719.     Address
  1720.     1\ 2\ 3\ 4\ 5\ 6\ 7\ 8
  1721. .LP
  1722.     \ \ A
  1723.     1\ 1\ 0\ 0\ 0\ 0\ 0\ 0
  1724. .LP
  1725.     \ \ B
  1726.     1\ 0\ 0\ 0\ 0\ 0\ 0\ 0
  1727. .PP
  1728. \fINote\fR \ \(em\ The DCE will discard all frames received with an address 
  1729. other than A or B; the DTE should do the same. 
  1730. .sp 1P
  1731. .LP
  1732. 2.7.2
  1733.     \fILAP procedure for the use of the P/F bit\fR 
  1734. .sp 9p
  1735. .RT
  1736. .PP
  1737. The DCE or DTE receiving an SARM, DISC, supervisory command or
  1738. I\ frame with the P\ bit set to\ 1 will set the F\ bit to\ 1 in the next 
  1739. response 
  1740. frame it transmits.
  1741. .PP
  1742. The response frame returned by the DCE to an SARM or DISC command with 
  1743. the P\ bit set to\ 1 will be a UA response with the F\ bit set to\ 1. The 
  1744. response frame returned by the DCE to an I\ frame with the P\ bit set to\ 
  1745. 1, received 
  1746. during the information transfer phase, will be an RR, REJ, RNR or CMDR 
  1747. response with the F\ bit set to\ 1. The response frame returned by the 
  1748. DCE to a 
  1749. supervisory command frame with the P\ bit set to\ 1, received during the
  1750. information transfer phase, will be an RR, RNR, REJ or CMDR response with 
  1751. the F\ bit set to\ 1. 
  1752. .PP
  1753. The P bit may be used by the DCE in conjunction with the timer
  1754. recovery condition (see \(sc\ 2.7.4.8 below).
  1755. .PP
  1756. \fINote\fR \ \(em\ Other use of the P bit by the DCE is a subject for further
  1757. study.
  1758. .RT
  1759. .sp 2P
  1760. .LP
  1761. 2.7.3
  1762.     \fILAP procedures for data link set\(hyup and disconnection\fR 
  1763. .sp 1P
  1764. .RT
  1765. .sp 1P
  1766. .LP
  1767. 2.7.3.1
  1768.     \fIData link set\(hyup\fR 
  1769. .sp 9p
  1770. .RT
  1771. .PP
  1772. The DCE will indicate that it is able to set up the data link by
  1773. transmitting contiguous flags (active channel state).
  1774. .PP
  1775. The DTE shall indicate a request for setting up the data link by
  1776. transmitting an SARM command to the DCE. Whenever receiving an SARM command,
  1777. the DCE will return a UA response to the DTE and set its receive state 
  1778. variable V(R) to\ 0. 
  1779. .bp
  1780. .PP
  1781. Should the DCE wish to indicate a request for setting up the data
  1782. link, or after transmission of a UA response to a first SARM command from 
  1783. the DTE as a request for setting up the data link, the DCE will transmit 
  1784. an SARM 
  1785. command to the DTE and start Timer\ T1 in order to determine when too much 
  1786. time has elapsed waiting for a reply (see \(sc\ 2.7.7.1 below). The DTE 
  1787. will confirm the reception of the SARM command by transmitting a UA response. 
  1788. When receiving the UA response the DCE will set its send state variable 
  1789. to 0 and stop its 
  1790. Timer\ T1.
  1791. .PP
  1792. If Timer T1 runs out before the UA response is received by the DCE,
  1793. the DCE will retransmit an SARM command and restart Timer T1. After
  1794. transmission of the SARM command N2 times by the DCE, appropriate recovery
  1795. action will be initiated. The value of N2 is defined in \(sc\ 2.7.7.4
  1796. below.
  1797. .RT
  1798. .sp 1P
  1799. .LP
  1800. 2.7.3.2
  1801.     \fIInformation transfer phase\fR 
  1802. .sp 9p
  1803. .RT
  1804. .PP
  1805. After having both transmitted the UA response to a received SARM
  1806. command and having received the UA response to a transmitted SARM command, 
  1807. the DCE will accept and transmit I and supervisory frames according to 
  1808. the 
  1809. procedures described in \(sc\ 2.7.4 below.
  1810. .PP
  1811. When receiving an SARM command, the DCE will conform to the data link resetting 
  1812. procedure described in \(sc\ 2.7.6 below. The DTE may also receive an 
  1813. SARM command while in the information transfer phase.
  1814. .RT
  1815. .sp 1P
  1816. .LP
  1817. 2.7.3.3
  1818.     \fIData link disconnection\fR 
  1819. .sp 9p
  1820. .RT
  1821. .PP
  1822. During the information transfer phase the DTE shall indicate a
  1823. request for disconnecting the data link by transmitting a DISC command 
  1824. to the DCE. Whenever receiving a DISC command, the DCE will return a UA 
  1825. response to 
  1826. the DTE.
  1827. .PP
  1828. During an information transfer phase, should the DCE wish to indicate a 
  1829. request for disconnecting the data link, or when receiving from the DTE 
  1830. a 
  1831. first DISC command as a request for disconnecting the data link, the DCE 
  1832. will transmit a DISC command to the DTE and start Timer T1 (see \(sc\ 2.7.7.1 
  1833. below). 
  1834. The DTE will confirm reception of the DISC command by returning a UA response. 
  1835. After transmitting an SARM command, the DCE will not transmit a DISC command 
  1836. until a UA response is received for this SARM command or until Timer T1 runs
  1837. out. When receiving a UA response to the DISC command, the DCE will stop its
  1838. Timer\ T1.
  1839. .PP
  1840. If Timer T1 runs out before a UA response is received by the DCE, the DCE 
  1841. will retransmit a DISC command and restart Timer\ T1. After transmission 
  1842. of the DISC command N2 times by the DCE, appropriate recovery action will 
  1843. be 
  1844. initiated. The value of N2 is defined in \(sc\ 2.7.7.4 below.
  1845. .RT
  1846. .sp 1P
  1847. .LP
  1848. 2.7.4
  1849.     \fILAP procedures for information transfer\fR 
  1850. .sp 9p
  1851. .RT
  1852. .PP
  1853. The procedures which apply to the transmission of I frames in each direction 
  1854. during the information transfer phase are described below. 
  1855. .PP
  1856. In the following, \*Qnumber 1 higher\*U is in reference to a continuously 
  1857. repeated sequence series, i.e.\ 7 is 1 higher than 6, and\ 0 is\ 1 higher 
  1858. than\ 7 for modulo 8\ series. 
  1859. .RT
  1860. .sp 1P
  1861. .LP
  1862. 2.7.4.1
  1863.     \fISending I frames\fR 
  1864. .sp 9p
  1865. .RT
  1866. .PP
  1867. When the DCE has an I frame to transmit (i.e.\ an I frame not
  1868. already transmitted, or having to be retransmitted as described in \(sc\ 
  1869. 2.7.4.5 
  1870. below), it will transmit it with an N(S) equal to its current send state
  1871. variable V(S), and an N(R) equal to its current receive state variable 
  1872. V(R). At the end of the transmission of the I\ frame, the DCE will increment 
  1873. its send 
  1874. state variable V(S) by\ 1.
  1875. .PP
  1876. If Timer T1 is not running at the time of transmission of an I frame, it 
  1877. will be started. 
  1878. .PP
  1879. If the send state variable V(S) is equal to the last value of N(R)
  1880. received plus \fIk\fR (where \fIk\fR is the maximum number of outstanding
  1881. I\ frames\ \(em\ see \(sc\ 2.7.7.6 below), the DCE will not transmit any 
  1882. new I\ frames, 
  1883. but may retransmit an I frame as described in \(sc\ 2.7.4.6 or \(sc\ 2.7.4.9
  1884. below.
  1885. .PP
  1886. When the DCE is in the busy condition, it may still transmit I frames provided 
  1887. that the DTE is not busy. When the DCE is in the command rejection 
  1888. condition, it may still transmit I\ frames.
  1889. .bp
  1890. .RT
  1891. .sp 1P
  1892. .LP
  1893. 2.7.4.2
  1894.     \fIReceiving an I frame\fR \v'3p'
  1895. .sp 9p
  1896. .RT
  1897. .PP
  1898. 2.7.4.2.1
  1899. When the DCE is not in a busy condition and receives a valid I\ frame whose 
  1900. send sequence number N(S) is equal to the DCE receive state variable V(R), 
  1901. the DCE will accept the information field of this frame, 
  1902. increment by\ 1 its receive state variable V(R), and act as follows:
  1903. .LP
  1904.     i)
  1905.     If an I frame is available for transmission by the DCE, it
  1906. may act as in \(sc\ 2.7.4.1 above and acknowledge the received
  1907. I\ frame by setting N(R) in the control field of the next
  1908. transmitted I\ frame to the value of the DCE receive state
  1909. variable V(R). Alternatively the DCE may acknowledge the
  1910. received I\ frame by transmitting an RR response with
  1911. the N(R) equal to the value of the DCE receive state
  1912. variable V(R).
  1913. .LP
  1914.     ii)
  1915.     If no I frame is available for transmission by the DCE, it
  1916. will transmit an RR response with\ N(R) equal to the value of the
  1917. DCE receive state variable\ V(R).
  1918. .PP
  1919. 2.7.4.2.2
  1920. When the DCE is in a busy condition, it may ignore the
  1921. information field contained in any received I\ frame.
  1922. .sp 1P
  1923. .LP
  1924. 2.7.4.3
  1925.     \fIReception of invalid frames\fR 
  1926. .sp 9p
  1927. .RT
  1928. .PP
  1929. When the DCE receives an invalid frame (see \(sc\ 2.6.5.3), this frame 
  1930. will be discarded. 
  1931. .RT
  1932. .sp 1P
  1933. .LP
  1934. 2.7.4.4
  1935.     \fIReception of out\(hyof\(hysequence I frames\fR 
  1936. .sp 9p
  1937. .RT
  1938. .PP
  1939. When the DCE receives a valid I frame whose FCS is correct, but
  1940. whose send sequence number N(S) is incorrect, i.e.\ not equal to the current
  1941. DCE receive state variable V(R), it will discard the information field 
  1942. of the I\ frame and transmit an REJ response with the N(R) set to one higher 
  1943. than the N(S) of the last correctly received I\ frame. The DCE will then 
  1944. discard the 
  1945. information field of all I\ frames received until the expected I\ frame is
  1946. correctly received. When receiving the expected I\ frame, the DCE will then
  1947. acknowledge the I\ frame as described in \(sc\ 2.7.4.2 above. The DCE will 
  1948. use the N(R) and P bit information in the discarded I\ frames as described 
  1949. in \(sc\ 2.6.5.2 above. 
  1950. .RT
  1951. .sp 1P
  1952. .LP
  1953. 2.7.4.5
  1954.     \fIReceiving acknowledgement\fR 
  1955. .sp 9p
  1956. .RT
  1957. .PP
  1958. When correctly receiving an I frame or a supervisory frame (RR, RNR or 
  1959. REJ), even in the busy condition, the DCE will consider the N(R) contained 
  1960. in this frame as an acknowledgement for all I\ frames it has transmitted 
  1961. with an N(S) up to and including the received N(R)\ \(em\ 1. The DCE will 
  1962. stop Timer T1 when it correctly receives an I\ frame or a supervisory frame 
  1963. with the N(R) higher 
  1964. than the last received N(R) (actually acknowledging some I\ frames) or an REJ
  1965. frame with an N(R) equal to the last received N(R).
  1966. .PP
  1967. If Timer T1 has been stopped and if there are outstanding I frames
  1968. still unacknowledged, the DCE will restart Timer T1. If Timer T1 then runs 
  1969. out, the DCE will follow the recovery procedure (in \(sc\(sc\ 2.7.4.6 and\ 
  1970. 2.7.4.9 below) 
  1971. with respect to the unacknowledged I\ frames.
  1972. .RT
  1973. .sp 1P
  1974. .LP
  1975. 2.7.4.6
  1976.     \fIReceiving an REJ frame\fR 
  1977. .sp 9p
  1978. .RT
  1979. .PP
  1980. When receiving an REJ frame, the DCE will set its send state
  1981. variable V(S) to the value of the N(R) received in the REJ control field. It
  1982. will transmit the corresponding I\ frame as soon as it is available or
  1983. retransmit it in accordance with the procedures described in \(sc\ 2.7.4.1 
  1984. above. (Re)transmission will conform to the following: 
  1985. .RT
  1986. .LP
  1987.     i)
  1988.     If the DCE is transmitting a supervisory or unnumbered
  1989. command or response when it receives the REJ frame, it will
  1990. complete that transmission before commencing transmission of the
  1991. requested I\ frame.
  1992. .LP
  1993.     ii)
  1994.     If the DCE is transmitting an I\ frame when the REJ frame is
  1995. received, it may abort the I\ frame and commence transmission
  1996. of the requested I\ frame immediately after abortion.
  1997. .LP
  1998.     iii)
  1999.     If the DCE is not transmitting any frame when the REJ
  2000. frame is received, it will commence transmission of the
  2001. requested I\ frame immediately.
  2002. .bp
  2003. .PP
  2004. In all cases, if other unacknowledged I frames have already been transmitted 
  2005. following the one indicated in the REJ frame, then those I\ frames will 
  2006. be retransmitted by the DCE following the retransmission of the requested 
  2007. I\ frame. Other I\ frames not yet transmitted may be transmitted following 
  2008. the 
  2009. retransmitted I\ frames.
  2010. .PP
  2011. If the REJ frame was received from the DTE as a command with the P bit 
  2012. set to\ 1, the DCE will transmit an RR or RNR response with the F\ bit 
  2013. set to\ 1 before transmitting or retransmitting the corresponding I\ frame. 
  2014. .RT
  2015. .sp 1P
  2016. .LP
  2017. 2.7.4.7
  2018.     \fIReceiving an RNR frame\fR 
  2019. .sp 9p
  2020. .RT
  2021. .PP
  2022. After receiving an RNR frame, the DCE may transmit or retransmit
  2023. the I\ frame with the send sequence number equal to the N(R) indicated in the
  2024. RNR frame. If Timer T1 runs out after the reception of the RNR frame, the 
  2025. DCE will follow the procedure described in \(sc\ 2.7.4.9 below. In any 
  2026. case, the DCE 
  2027. will not transmit any other I\ frames before receiving an RR or REJ frame, or
  2028. before the completion of a data link resetting procedure.
  2029. .RT
  2030. .sp 1P
  2031. .LP
  2032. 2.7.4.8
  2033.     \fIDCE busy condition\fR 
  2034. .sp 9p
  2035. .RT
  2036. .PP
  2037. When the DCE enters a busy condition, it will transmit an RNR
  2038. response at the earliest opportunity. While in the busy condition, the 
  2039. DCE will accept and process supervisory frames, will accept and process 
  2040. the contents of the N(R) fields of I\ frames, and will return an RNR response 
  2041. with the F\ bit set to\ 1 if it receives a supervisory command or\ I command 
  2042. frame with the P\ bit set to\ 1. To clear the busy condition, the DCE will 
  2043. transmit either an REJ response or an RR response, with N(R) set to the 
  2044. current receive state variable V(R), 
  2045. depending on whether or not it discarded information fields of correctly
  2046. received I\ frames.
  2047. .PP
  2048. \fINote\fR \ \(em\ The DTE when encountering a DCE busy condition, may send
  2049. supervisory command frames with the P bit set to\ 1. In the event that 
  2050. the DTE has not implemented supervisory commands, it may follow the procedures 
  2051. of the DCE (see \(sc\ 2.7.4.7). 
  2052. .RT
  2053. .sp 1P
  2054. .LP
  2055. 2.7.4.9
  2056.     \fIWaiting acknowledgement\fR 
  2057. .sp 9p
  2058. .RT
  2059. .PP
  2060. The DCE maintains an internal transmission attempt variable which is set 
  2061. to\ 0 when the DCE sends a UA response, when the DCE receives a UA 
  2062. response or an RNR command or response, or when the DCE correctly receives 
  2063. an I\ frame or supervisory frame with the N(R) higher than the last received 
  2064. N(R) (actually acknowledging some outstanding I\ frames). 
  2065. .PP
  2066. If Timer T1 runs out waiting for the acknowledgement from the DTE for an 
  2067. I\ frame transmitted, the DCE will enter the timer recovery condition, 
  2068. add 
  2069. one to its transmission attempt variable and set an internal variable \fIx\fR 
  2070. to 
  2071. the current value of its send state variable\ V(S).
  2072. .PP
  2073. The DCE will restart Timer T1, set its send state variable V(S) to the 
  2074. last N(R) received from the DTE, and retransmit the corresponding I\ frame 
  2075. with the P\ bit set to\ 1. 
  2076. .PP
  2077. The timer recovery condition is cleared when the DCE receives a valid supervisory 
  2078. frame from the DTE, with the F\ bit set to\ 1. 
  2079. .PP
  2080. If, while in the timer recovery condition, the DCE correctly receives a 
  2081. supervisory frame with the F\ bit set to\ 1 and with an N(R) within the 
  2082. range from its current send state variable V(S) to\ \fIx\fR included, it 
  2083. will clear the 
  2084. timer recovery condition (including stopping Timer\ T1) and set its send 
  2085. state variable V(S) to the received N(R), and may then resume with I\ frame 
  2086. transmission or retransmission, as appropriate.
  2087. .PP
  2088. If, while in the timer recovery condition, the DCE correctly receives an\ 
  2089. I or supervisory frame with the P/F bit set to\ 0 and with N(R) within 
  2090. the 
  2091. range from its current send state variable V(S) to \fIx\fR included, it 
  2092. will not 
  2093. clear the timer recovery condition. The value of the received N(R) may 
  2094. be used to update the send state variable V(S). However, the DCE may decide 
  2095. to keep the last transmitted I frame in store (even if it is acknowledged) 
  2096. in order to be able to retransmit it with the P\ bit set to\ 1 when Timer 
  2097. T1 runs out at a later time. 
  2098. .PP
  2099. If Timer T1 runs out in the timer recovery condition, the DCE will add 
  2100. one to its transmission attempt variable, restart Timer T1, and retransmit 
  2101. the I\ frame sent with the P\ bit set to\ 1. 
  2102. .bp
  2103. .PP
  2104. If the transmission attempt variable is equal to N2, the DCE will
  2105. initiate a data link resetting procedure for the direction of transmission 
  2106. from the DCE as described in \(sc\ 2.7.6.3 below. N2 is a system parameter 
  2107. (see 
  2108. \(sc\ 2.7.7.4 below).
  2109. .PP
  2110. \fINote\fR \ \(em\ Although the DCE may implement the internal variable 
  2111. \fIx\fR , 
  2112. other mechanisms do exist that achieve the identical function. Therefore, 
  2113. the internal variable \fIx\fR is not necessarily implemented in the DTE. 
  2114. .RT
  2115. .sp 2P
  2116. .LP
  2117. 2.7.5
  2118.     \fILAP command rejection conditions\fR 
  2119. .sp 1P
  2120. .RT
  2121. .sp 1P
  2122. .LP
  2123. 2.7.5.1
  2124.     \fIRejection conditions causing a data link resetting of the\fR 
  2125. \fItransmission of information from the DCE\fR 
  2126. .sp 9p
  2127. .RT
  2128. .PP
  2129. The DCE will initiate a data link resetting procedure as described in \(sc\ 
  2130. 2.7.6.3 below when receiving a frame which is not invalid (see \(sc\ 2.6.5.3) 
  2131. with the address\ A (coded\ 11000000) and with one of the following 
  2132. conditions:
  2133. .RT
  2134. .LP
  2135.     \(em
  2136.     the frame type is unknown as one of the responses supported;
  2137. .LP
  2138.     \(em
  2139.     the information field is invalid;
  2140. .LP
  2141.     \(em
  2142.     the N(R) contained in the control field is invalid; or
  2143. .LP
  2144.     \(em
  2145.     the response contains an F bit set to 1 except during a timer
  2146. recovery condition as described in \(sc\ 2.7.4.9
  2147. above.
  2148. .PP
  2149. The DCE will also initiate a data link resetting procedure as
  2150. described in \(sc\ 2.7.6.3 below when receiving an I or supervisory frame 
  2151. which is not invalid (see \(sc\ 2.6.5.3) with the address\ B (coded\ 10000000) 
  2152. and with an 
  2153. invalid N(R) contained in the control field.
  2154. .PP
  2155. A valid N(R) must be within the range from the lowest send sequence
  2156. number N(S) of the still unacknowledged frame(s) to the current DCE send 
  2157. state variable V(S) included, even if the DCE is in a rejection condition, 
  2158. but 
  2159. not if the DCE is in the timer recovery condition (see \(sc\ 2.7.4.9
  2160. above).
  2161. .RT
  2162. .sp 1P
  2163. .LP
  2164. 2.7.5.2
  2165.     \fIRejection conditions causing the DCE to request a data link\fR 
  2166. \fIresetting of the transmission of information from the DTE\fR 
  2167. .sp 9p
  2168. .RT
  2169. .PP
  2170. The DCE will enter the command rejection condition as described in \(sc\ 
  2171. 2.7.6.5 below when receiving a frame which is not invalid (see \(sc\ 2.6.5.3) 
  2172. with the address\ B (coded\ 10000000) and with one of the following
  2173. conditions:
  2174. .RT
  2175. .LP
  2176.     \(em
  2177.     the frame type is unknown as one of the commands supported;   or
  2178. .LP
  2179.     \(em
  2180.     the information field is invalid.
  2181. .sp 1P
  2182. .LP
  2183. 2.7.6
  2184.     \fILAP procedures for data link resetting\fR \v'3p'
  2185. .sp 9p
  2186. .RT
  2187. .PP
  2188. 2.7.6.1
  2189. The data link resetting procedure is used to reinitialize one
  2190. direction of information transfer according to the procedure described 
  2191. below. The data link resetting procedures only apply during the information 
  2192. transfer phase. 
  2193. .PP
  2194. 2.7.6.2
  2195. The DTE will indicate a data link resetting of the information
  2196. transmission from the DTE by transmitting an SARM command to the DCE. When
  2197. receiving an SARM command correctly, the DCE will return, at the earliest
  2198. opportunity, a UA response to the DTE and set its receive state variables 
  2199. V(R) to zero. This also indicates a clearance of a DCE and/or DTE busy 
  2200. condition, if present. 
  2201. .PP
  2202. 2.7.6.3
  2203. The DCE will indicate a data link resetting of the information
  2204. transmitted from the DCE by transmitting an SARM command to the DTE and will
  2205. start Timer\ T1 (see \(sc\ 2.7.7.1 below). The DTE will confirm reception 
  2206. of the 
  2207. SARM command by returning a UA response to the DCE. When receiving this UA
  2208. response to the SARM command, the DCE will set its send state variable V(S)
  2209. to\ 0 and stop its Timer T1. If Timer T1 runs out before the UA response is
  2210. received by the DCE, the DCE will retransmit an SARM command and restart
  2211. Timer\ T1. After transmission of the SARM command\ N2 times, appropriate 
  2212. higher layer recovery action will be initiated. The value of N2 is defined 
  2213. in 
  2214. \(sc\ 2.7.7.4 below.
  2215. .PP
  2216. The DCE will not act on any received response frame which arrives before 
  2217. the UA response command. The value of N(R) contained in any correctly 
  2218. received\ I command frame arriving before the UA response will also be
  2219. ignored.
  2220. .PP
  2221. 2.7.6.4
  2222. When receiving a CMDR response from the DTE, the DCE will
  2223. initiate a data link resetting of the information transmission from the 
  2224. DCE as described in \(sc\ 2.7.6.3 above. 
  2225. .bp
  2226. .PP
  2227. 2.7.6.5
  2228. If the DCE transmits a CMDR response, it enters the command
  2229. rejection condition. The command rejection condition is cleared when the DCE
  2230. receives an SARM or DISC command. Any other command received while in the
  2231. command rejection condition will cause the DCE to retransmit the CMDR
  2232. response. The coding of the CMDR response will be as described in \(sc\ 2.6.4.8
  2233. above.
  2234. .sp 1P
  2235. .LP
  2236. 2.7.7
  2237.     \fIList of\fR 
  2238. \fILAP system parameters\fR 
  2239. .sp 9p
  2240. .RT
  2241. .PP
  2242. The DCE and DTE system parameters are as follows:
  2243. .RT
  2244. .sp 1P
  2245. .LP
  2246. 2.7.7.1
  2247.     \fITimer T1\fR 
  2248. .sp 9p
  2249. .RT
  2250. .PP
  2251. The value of the DTE Timer\ T1 system parameter may be different
  2252. than the value of the DCE Timer\ T1 system parameter. These values shall 
  2253. be made known to both the DTE and the DCE, and agreed to for a period of 
  2254. time by both the DTE and the DCE. 
  2255. .PP
  2256. The period of Timer\ T1, at the end of which retransmission of a frame 
  2257. may be initiated (see \(sc\(sc\ 2.7.4 and\ 2.7.5 above for the DCE), shall 
  2258. take into 
  2259. account whether T1 is started at the beginning or the end of the transmission 
  2260. of a frame. 
  2261. .PP
  2262. The proper operation of the procedure requires that the transmitter's (DCE 
  2263. or DTE) Timer\ T1 be greater than the maximum time between transmission 
  2264. of a frame (SARM, DISC, I, or supervisory command, or CMDR response) and 
  2265. the 
  2266. reception of the corresponding frame returned as an answer to that frame 
  2267. (UA or acknowl 
  2268. edging\ frame). Therefore, the receiver (DCE or DTE) should not delay the 
  2269. response or acknowledging frame returned to one of the above frames by 
  2270. more than a value\ T2, where T2 is a system parameter (see \(sc\ 2.7.7.2). 
  2271. .PP
  2272. The DCE will not delay the response or acknowledging frame returned to 
  2273. one of the above DTE frames by more than a period\ T2. 
  2274. .RT
  2275. .sp 1P
  2276. .LP
  2277. 2.7.7.2
  2278.     \fIParameter T2\fR 
  2279. .sp 9p
  2280. .RT
  2281. .PP
  2282. The value of the DTE parameter T2 may be different than the value of the 
  2283. DCE parameter\ T2. These values shall be made known to both the DTE 
  2284. and the DCE, and agreed to for a period of time by both the DTE and the
  2285. DCE.
  2286. .PP
  2287. The period of parameter T2 shall indicate the amount of time available 
  2288. at the DCE or DTE before the acknowledging frame must be initiated in order 
  2289. to ensure its receipt by the DTE or DCE, respectively, prior to Timer\ 
  2290. T1 running out at the DTE or DCE (parameter T2\ <\ Timer T1). 
  2291. .PP
  2292. \fINote\fR \ \(em\ The period of parameter T2 shall take into account the
  2293. following timing factors: the transmission time of the acknowledging frame, 
  2294. the propagation time over the access data link, the state processing times 
  2295. at the DCE and the DTE, and the time to complete the transmission of the 
  2296. frames in the DCE or DTE transmit queue that are neither displaceable or 
  2297. modifiable in an 
  2298. orderly manner.
  2299. .PP
  2300. Given a value for Timer\ T1 for the DTE or DCE, the value of
  2301. parameter\ T2 at the DCE or DTE, respectively, must be no larger than T1 
  2302. minus 2\ times the propagation time over the access data link, minus the 
  2303. frame 
  2304. processing time at the DCE, minus the frame processing time at the DTE, and
  2305. minus the transmission time of the acknowledging frame by the DCE or DTE,
  2306. respectively.
  2307. .RT
  2308. .sp 1P
  2309. .LP
  2310. 2.7.7.3
  2311.     \fITimer T3\fR 
  2312. .sp 9p
  2313. .RT
  2314. .PP
  2315. The DCE shall support a Timer T3 system parameter, the value of
  2316. which shall be made known to 
  2317. the\ DTE.
  2318. .PP
  2319. The period of Timer T3, at the end of which an indication of an
  2320. observed excessively long idle link channel state condition is passed to the
  2321. Packet Layer, shall be sufficiently greater than the period of the DCE 
  2322. Timer\ T1 (i.e.\ T3\ >\ T1) so that the expiration of T3 provides the desired 
  2323. level of 
  2324. assurance that the data link channel is in a non\(hyactive, non\(hyoperational
  2325. state, and is in need of data link set\(hyup before normal data link operation
  2326. can resume.
  2327. .RT
  2328. .sp 1P
  2329. .LP
  2330. 2.7.7.4
  2331.     \fIMaximum number of attempts to complete a transmission N2\fR 
  2332. .sp 9p
  2333. .RT
  2334. .PP
  2335. The value of the DTE N2 system parameter may be different than the value 
  2336. of the DCE N2 system parameter. These values shall be made known to both 
  2337. the DTE and the DCE, and agreed to for a period of time by both the DTE 
  2338. and the DCE. 
  2339. .PP
  2340. The value of N2 shall indicate the maximum number of attempts made by the 
  2341. DCE or DTE to complete the successful transmission of a frame to the DTE 
  2342. or DCE, respectively. 
  2343. .bp
  2344. .RT
  2345. .sp 1P
  2346. .LP
  2347. 2.7.7.5
  2348.     \fIMaximum number of bits in an I frame N1\fR 
  2349. .sp 9p
  2350. .RT
  2351. .PP
  2352. The value of the DTE N1 system parameter may be different than the value 
  2353. of the DCE\ N1 system parameter. These values shall be made known to both 
  2354. the DTE and the DCE. 
  2355. .PP
  2356. The values of N1 shall indicate the maximum number of bits in an
  2357. I\ frame (excluding flags and 0\ bits inserted for transparency) that the 
  2358. DCE or DTE is willing to accept from the DTE or DCE, respectively. 
  2359. .PP
  2360. In order to allow for universal operation, a DTE should support a
  2361. value of DTE\ N1 which is not less than 1080\ bits (135\ octets). DTEs 
  2362. should be aware that the network may transmit longer packets (see \(sc\ 
  2363. 5.2), that may result in a data link layer problem. 
  2364. .PP
  2365. All networks shall offer to a DTE which requires it, a value of DCE\ N1 
  2366. which is greater than or equal to 2072\ bits (259\ octets) plus the length 
  2367. of the address, control and FCS fields at the DTE/DCE interface, and greater 
  2368. than or equal to the maximum length of the data packets which may cross 
  2369. the DTE/DCE 
  2370. interface plus the length of the address, control and FCS fields at the 
  2371. DTE/DCE interface. 
  2372. .RT
  2373. .sp 1P
  2374. .LP
  2375. 2.7.7.6
  2376.     \fIMaximum number of outstanding I frames k\fR 
  2377. .sp 9p
  2378. .RT
  2379. .PP
  2380. The value of the DTE k\ system parameter shall be the same as the
  2381. value of the DCE k\ system parameter. This value shall be agreed to for a
  2382. period of time by both the DTE and the DCE.
  2383. .PP
  2384. The value of k shall indicate the maximum number of sequentially
  2385. numbered I\ frames that the DTE of DCE may have outstanding
  2386. (i.e.\ unacknowledged) at any given time. The value of\ k shall never exceed
  2387. seven. All networks (DCEs) shall support a value of seven. Other values of\ k
  2388. (less than seven) may also be supported by networks (DCEs).
  2389. .RT
  2390. .sp 2P
  2391. .LP
  2392. \fB3\fR     \fBDescription of the\fR 
  2393. \fBpacket level DTE/DCE interface\fR 
  2394. .sp 1P
  2395. .RT
  2396. .PP
  2397. This and subsequent sections of the Recommendation relate to the
  2398. transfer of packets at the DTE/DCE interface. The procedures apply to packets 
  2399. which are successfully transferred across the DTE/DCE interface. 
  2400. .PP
  2401. Each packet to be transferred across the DTE/DCE interface shall be
  2402. contained within the data link layer information field which will delimit 
  2403. its length, and only one packet shall be contained in the information field. 
  2404. .PP
  2405. \fINote\fR \ \(em\ Some networks require the data fields of packets to 
  2406. contain an integral number of octets. The transmission by the DTE of data 
  2407. fields not 
  2408. containing an integral number of octets to the network may cause a loss 
  2409. of data integrity. DTEs wishing universal operation on all networks should 
  2410. transmit 
  2411. all packets with data fields containing only an integral number of octets. 
  2412. Full data integrity can only be assured by exchange of octet\(hyoriented 
  2413. data fields in both directions of transmission. 
  2414. .PP
  2415. This section covers a description of the packet layer interface for
  2416. virtual call and permanent virtual circuit services.
  2417. .PP
  2418. Procedures for the virtual circuit service (i.e.,\ virtual call and
  2419. permanent virtual circuit services) are specified in \(sc\ 4. Packet formats 
  2420. are 
  2421. specified in \(sc\ 5. Procedures and formats for optional user facilities are
  2422. specified in \(sc\(sc\ 6 and\ 7.
  2423. .RT
  2424. .sp 1P
  2425. .LP
  2426. 3.1
  2427.     \fILogical channels\fR 
  2428. .sp 9p
  2429. .RT
  2430. .PP
  2431. To enable simultaneous virtual calls and/or permanent virtual
  2432. circuits, logical channels are used. Each virtual call or permanent virtual
  2433. circuit is assigned a logical channel group number (less than or equal 
  2434. to\ 15) and a logical channel number (less than or equal to\ 255). For 
  2435. virtual calls, a logical channel group number and a logical channel number 
  2436. are assigned during the call set\(hyup phase. The range of logical channels 
  2437. used for virtual calls is agreed with the Administration at the time of 
  2438. subscription to the service (see Annex\ A). For permanent virtual circuits, 
  2439. logical channel group numbers and 
  2440. logical channel numbers are assigned in agreement with the Administration at
  2441. the time of subscription to the service (see Annex\ A).
  2442. .bp
  2443. .RT
  2444. .sp 1P
  2445. .LP
  2446. 3.2
  2447.     \fIBasic structure of packets\fR 
  2448. .sp 9p
  2449. .RT
  2450. .PP
  2451. Every packet transferred across the DTE/DCE interface consists of at least 
  2452. three octets. These three octets contain a general format identifier, a 
  2453. logical channel identifier and a packet type identifier. Other packet fields 
  2454. are appended as required (see \(sc\ 5). 
  2455. .PP
  2456. Packet types and their use in association with various services are
  2457. given in Table\ 14/X.25.
  2458. .RT
  2459. .LP
  2460. .sp 4
  2461. .ce
  2462. \fBH.T. [T12.25]\fR 
  2463. .ce
  2464. TABLE\ 14/X.25
  2465. .ce
  2466. \fBPacket types and their use in various services\fR 
  2467. .ps 9
  2468. .vs 11
  2469. .nr VS 11
  2470. .nr PS 9
  2471. .TS
  2472. center box;
  2473. cw(174p) | cw(36p) .
  2474. Packet type    Service
  2475. _
  2476. .T&
  2477. lw(90p) | lw(84p) | cw(18p) | cw(18p) .
  2478. From DCE to DTE    From DTE to DCE    VC      PVC
  2479. _
  2480. .T&
  2481. cw(174p) | lw(18p) | lw(18p) .
  2482. T{
  2483. \fICall set\(hyup and clearing\fR
  2484. (see Note 1)
  2485. T}        
  2486. .T&
  2487. lw(90p) | lw(84p) | cw(18p) | lw(18p) .
  2488. Incoming call    Call request    X    
  2489. .T&
  2490. lw(90p) | lw(84p) | cw(18p) | lw(18p) .
  2491. Call connected    Call accepted    X    
  2492. .T&
  2493. lw(90p) | lw(84p) | cw(18p) | lw(18p) .
  2494. Clear indication    Clear request    X    
  2495. .T&
  2496. lw(90p) | lw(84p) | cw(18p) | lw(18p) .
  2497. DCE clear confirmation    DTE clear confirmation    X    
  2498. .T&
  2499. cw(174p) | lw(18p) | lw(18p) .
  2500. T{
  2501. \fIData and interrupt\fR
  2502. (see Note 2)
  2503. T}        
  2504. .T&
  2505. lw(90p) | lw(84p) | cw(18p) | cw(18p) .
  2506. DCE data    DTE data    X    X
  2507. .T&
  2508. lw(90p) | lw(84p) | cw(18p) | cw(18p) .
  2509. DCE interrupt    DTE interrupt    X    X
  2510. .T&
  2511. lw(90p) | lw(84p) | cw(18p) | cw(18p) .
  2512. DCE interrupt confirmation    DTE interrupt confirmation    X    X
  2513. .T&
  2514. cw(174p) | lw(18p) | lw(18p) .
  2515. T{
  2516. \fIFlow control and reset\fR
  2517. (see Note 3)
  2518. T}        
  2519. .T&
  2520. lw(90p) | lw(84p) | cw(18p) | cw(18p) .
  2521. DCE RR    DTE RR    X    X
  2522. .T&
  2523. lw(90p) | lw(84p) | cw(18p) | cw(18p) .
  2524. DCE RNR    DTE RNR    X    X
  2525. .T&
  2526. lw(90p) | lw(84p) | cw(18p) | cw(18p) .
  2527.     DTE REJ\|\ua\d\u)\d    X    X
  2528. .T&
  2529. lw(90p) | lw(84p) | cw(18p) | cw(18p) .
  2530. Reset indication    Reset request    X    X
  2531. .T&
  2532. lw(90p) | lw(84p) | cw(18p) | cw(18p) .
  2533. DCE reset confirmation    DTE reset confirmation    X    X
  2534. .T&
  2535. cw(174p) | lw(18p) | lw(18p) .
  2536. T{
  2537. \fIRestart\fR
  2538. (see Note 4)
  2539. T}        
  2540. .T&
  2541. lw(90p) | lw(84p) | cw(18p) | cw(18p) .
  2542. Restart indication    Restart request    X    X
  2543. .T&
  2544. lw(90p) | lw(84p) | cw(18p) | cw(18p) .
  2545. DCE restart confirmation    DTE restart confirmation    X    X
  2546. .T&
  2547. cw(174p) | lw(18p) | lw(18p) .
  2548. T{
  2549. \fIDiagnostic\fR
  2550. (see Note 5)
  2551. T}        
  2552. .T&
  2553. lw(90p) | lw(84p) | cw(18p) | cw(18p) .
  2554. Diagnostic\|\ua\d\u)\d        X    X
  2555. .T&
  2556. cw(174p) | lw(18p) | lw(18p) .
  2557. T{
  2558. \fIRegistration\fR
  2559. \|\ua\d\u)\d (see Note 6)
  2560. T}        
  2561. .T&
  2562. lw(90p) | lw(84p) | cw(18p) | cw(18p) .
  2563. Registration Confirmation        X    X
  2564. .T&
  2565. lw(90p) | lw(84p) | cw(18p) | cw(18p) .
  2566.     Registration Request    X    T{
  2567. X
  2568. \ua\d\u)\d\ Not necessarily available on all networks.
  2569. .parag
  2570. VC
  2571. Virtual call
  2572. PVC
  2573. Permanent virtual circuit
  2574. .parag
  2575. \fINote\ 1\fR
  2576. \ \(em\ See \(sc\(sc\ 4.1 and 6.16 for procedures, \(sc\ 5.2 for formats.
  2577. .parag
  2578. \fINote\ 2\fR
  2579. \ \(em\ See \(sc\ 4.3 for procedures and \(sc\ 5.3 for formats.
  2580. .parag
  2581. \fINote\ 3\fR
  2582. \ \(em\ See \(sc\(sc\ 4.4 and 6.4 for procedures, \(sc\(sc\ 5.4 and 5.7.1 for formats.
  2583. .parag
  2584. \fINote\ 4\fR
  2585. \ \(em\ See \(sc\ 3.3 for procedures and \(sc\ 5.5 for formats.
  2586. .parag
  2587. \fINote\ 5\fR
  2588. \ \(em\ See \(sc\ 3.4 for procedures and \(sc\ 5.6 for formats.
  2589. .parag
  2590. \fINote\ 6\fR
  2591. \ \(em\ See \(sc\ 6.1 for procedures and \(sc\ 5.7.2 for formats.
  2592. .parag
  2593. T}
  2594. _
  2595. .TE
  2596. .nr PS 9
  2597. .RT
  2598. .ad r
  2599. \fBTable 14/X.25 [T12.25], p.\fR 
  2600. .sp 1P
  2601. .RT
  2602. .ad b
  2603. .RT
  2604. .LP
  2605. .bp
  2606. .sp 1P
  2607. .LP
  2608. 3.3
  2609.     \fIProcedure for\fR 
  2610. \fIrestart\fR 
  2611. .sp 9p
  2612. .RT
  2613. .PP
  2614. The restart procedure is used to initialize or reinitialize the
  2615. packet layer DTE/DCE interface. The restart procedure simultaneously clears 
  2616. all the virtual calls and resets all the permanent virtual circuits at 
  2617. the 
  2618. DTE/DCE interface (see \(sc\ 4.5).
  2619. .PP
  2620. Figure\ B\(hy1/X.25 gives the state diagram which defines the logical
  2621. relationships of events related to the restart procedure.
  2622. .PP
  2623. Table C\(hy2/X.25 specifies actions taken by the DCE on the receipt of
  2624. packets from the DTE for the restart procedure.
  2625. .RT
  2626. .sp 1P
  2627. .LP
  2628. 3.3.1
  2629.     \fIRestart by the DTE\fR 
  2630. .sp 9p
  2631. .RT
  2632. .PP
  2633. The DTE may at any time request a restart by transferring across
  2634. the DTE/DCE interface a \fIrestart request\fR packet. The interface for each
  2635. logical channel is then in the \fIDTE restart request\fR state\ (r2).
  2636. .PP
  2637. The DCE will confirm the restart by transferring a \fIDCE restart\fR 
  2638. \fIconfirmation packet\fR \| and placing the logical channels used for 
  2639. virtual calls in the \fIready\fR state (p1), and the logical channels used 
  2640. for permanent virtual circuits in the \fIflow control ready\fR state (d1). 
  2641. .PP
  2642. \fINote\fR \ \(em\ States p1 and d1 are specified in \(sc\ 4.
  2643. .PP
  2644. The \fIDCE restart confirmation\fR \|packet can only be interpreted
  2645. universally as having local significance. The time spent in the \fIDTE 
  2646. restart\fR \fIrequest\fR state (r2) will not exceed time\(hylimit T20 (see 
  2647. Annex\ D). 
  2648. .RT
  2649. .sp 1P
  2650. .LP
  2651. 3.3.2
  2652.     \fIRestart by the DCE\fR 
  2653. .sp 9p
  2654. .RT
  2655. .PP
  2656. The DCE may indicate a restart by transferring across the DTE/DCE
  2657. interface a \fIrestart indication\fR \|packet. The interface for each logical
  2658. channel is then in the \fIDCE restart indication\fR state (r3). In this 
  2659. state of 
  2660. the DTE/DCE interface, the DCE will ignore all packets except for \fIrestart\fR 
  2661. \fIrequest\fR and \fIDTE restart confirmation\fR .
  2662. .PP
  2663. The DTE will confirm the restart by transferring a \fIDTE restart\fR 
  2664. \fIconfirmation\fR \|packet and placing the logical channels used for virtual 
  2665. calls in the \fIready\fR state\ (p1), and the logical channels used for 
  2666. permanent virtual circuits in the \fIflow control ready\fR state\ (d1). 
  2667. .PP
  2668. The action taken by the DCE when the DTE does not confirm the restart within 
  2669. time\(hyout T10 is given in Annex\ D. 
  2670. .RT
  2671. .sp 1P
  2672. .LP
  2673. 3.3.3
  2674.     \fIRestart collision\fR 
  2675. .sp 9p
  2676. .RT
  2677. .PP
  2678. Restart collision occurs when a DTE and a DCE simultaneously
  2679. transfer a \fIrestart request\fR \|and a \fIrestart indication\fR packet. 
  2680. Under these 
  2681. circumstances, the DCE will consider that the restart is completed. The DCE
  2682. will not expect a \fIDTE restart confirmation\fR packet and will not transfer a
  2683. \fIDCE restart confirmation\fR packet. This places the logical channels 
  2684. used for 
  2685. virtual calls in the \fIready\fR state\ (p1), and the logical channels used for
  2686. permanent virtual circuits in the \fIflow control ready\fR state\ (d1).
  2687. .RT
  2688. .sp 1P
  2689. .LP
  2690. 3.4
  2691.     \fIError handling\fR 
  2692. .sp 9p
  2693. .RT
  2694. .PP
  2695. Table C\(hy1/X.25 specifies the reaction of the DCE when special error 
  2696. conditions are encountered. Other error conditions are discussed in 
  2697. \(sc\ 4.
  2698. .RT
  2699. .sp 1P
  2700. .LP
  2701. 3.4.1
  2702.     \fIDiagnostic packet\fR 
  2703. .sp 9p
  2704. .RT
  2705. .PP
  2706. The \fIdiagnostic\fR \|packet is used by some networks to indicate error 
  2707. conditions under circumstances where the usual methods of indication 
  2708. (i.e.\ \fIreset\fR , \fIclear\fR and \fIrestart\fR with cause and diagnostic) 
  2709. are 
  2710. inappropriate (see Tables\ C\(hy1/X.25 and D\(hy1/X.25). The \fIdiagnostic\fR 
  2711. packet from the DCE supplies information on error situations which are 
  2712. considered 
  2713. unrecoverable at the packet layer of Recommendation\ X.25; the information
  2714. provided permits an analysis of the error and recovery by higher layers 
  2715. at the DTE if desired or possible. 
  2716. .PP
  2717. A \fIdiagnostic\fR \|packet is issued only once per particular instance 
  2718. of an error condition. No confirmation is required to be issued by the 
  2719. DTE on 
  2720. receipt of a \fIdiagnostic\fR packet.
  2721. .bp
  2722. .RT
  2723. .sp 2P
  2724. .LP
  2725. \fB4\fR     \fBProcedures for virtual circuit services\fR 
  2726. .sp 1P
  2727. .RT
  2728. .sp 1P
  2729. .LP
  2730. 4.1
  2731.     \fIProcedures for\fR 
  2732. \fIvirtual call service\fR 
  2733. .sp 9p
  2734. .RT
  2735. .PP
  2736. Figures B\(hy1/X.25, B\(hy2/X.25 and B\(hy3/X.25 show the state diagrams
  2737. which define the events at the packet layer DTE/DCE interface for each
  2738. logical channel
  2739. used for virtual calls.
  2740. .PP
  2741. Annex C gives details of the action taken by the DCE on receipt of
  2742. packets in each state shown in Annex\ B.
  2743. .PP
  2744. The call set\(hyup and clearing procedures described in the following
  2745. points apply independently to each logical channel assigned to the
  2746. virtual call
  2747. service at the DTE/DCE interface.
  2748. .RT
  2749. .sp 1P
  2750. .LP
  2751. 4.1.1
  2752.     \fIReady state\fR 
  2753. .sp 9p
  2754. .RT
  2755. .PP
  2756. If there is no call in existence, a logical channel is in the
  2757. ready state\ (p1).
  2758. .RT
  2759. .LP
  2760. .sp 1P
  2761. .LP
  2762. 4.1.2
  2763.     \fICall request packet\fR 
  2764. .sp 9p
  2765. .RT
  2766. .PP
  2767. The calling DTE shall indicate a call request by transferring a
  2768. \fIcall request\fR \|packet across the DTE/DCE interface. The logical channel
  2769. selected by the DTE is then in the \fIDTE waiting\fR state\ (p2). The \fIcall 
  2770. request\fR packet includes the called DTE address. 
  2771. .PP
  2772. \fINote\ 1\fR \ \(em\ A DTE address may be a DTE network address or any 
  2773. other DTE identification agreed for a period of time between the DTE and 
  2774. the DCE. 
  2775. .PP
  2776. \fINote\ 2\fR \ \(em\ The call request packet should use the logical channel
  2777. in the \fIready\fR \| state with the highest number in the range which has been
  2778. agreed with the Administration (see Annex\ A). Thus the risk of call collision 
  2779. is minimized. 
  2780. .RT
  2781. .sp 1P
  2782. .LP
  2783. 4.1.3
  2784.     \fIIncoming call packet\fR 
  2785. .sp 9p
  2786. .RT
  2787. .PP
  2788. The DCE will indicate that there is an incoming call by
  2789. transferring across the DTE/DCE interface an \fIincoming call\fR packet. This
  2790. places the logical channel in the \fIDCE waiting\fR state\ (p3).
  2791. .PP
  2792. The \fIincoming call\fR \|packet will use the logical channel in the \fIready\fR 
  2793. \| state with the lowest number (see Annex\ A). The \fIincoming call\fR 
  2794. packet includes the calling DTE address. 
  2795. .PP
  2796. \fINote\fR \ \(em\ A DTE address may be a DTE network address or any other 
  2797. DTE identification agreed for a period of time between the DTE and the 
  2798. DCE.
  2799. .RT
  2800. .sp 1P
  2801. .LP
  2802. 4.1.4
  2803.     \fICall accepted packet\fR 
  2804. .sp 9p
  2805. .RT
  2806. .PP
  2807. The called DTE shall indicate its acceptance of the call by
  2808. transferring across the DTE/DCE interface a \fIcall accepted\fR packet 
  2809. specifying the same logical channel as that of the \fIincoming call\fR 
  2810. packet. This places the specified logical channel in the \fIdata transfer\fR 
  2811. state\ (p4). 
  2812. .PP
  2813. If the called DTE does not accept the call by a \fIcall accepted\fR \|packet 
  2814. or does not reject it by a \fIclear request\fR packet as described in \(sc\ 
  2815. 4.1.7 
  2816. within time\(hyout T11 (see Annex\ D), the DCE will consider it as a procedure
  2817. error from the called DTE and will clear the virtual call according to the
  2818. procedure described in \(sc\ 4.1.8.
  2819. .RT
  2820. .sp 1P
  2821. .LP
  2822. 4.1.5
  2823.     \fICall connected packet\fR 
  2824. .sp 9p
  2825. .RT
  2826. .PP
  2827. The receipt of a \fIcall connected\fR \|packet by the calling DTE
  2828. specifying the same logical channel as that specified in the \fIcall request\fR 
  2829. packet indicates that the call has been accepted by the called DTE by means 
  2830. of a \fIcall accepted\fR packet. This places the specified logical channel 
  2831. in the 
  2832. \fIdata transfer\fR state\ (p4).
  2833. .PP
  2834. The time spent in the \fIDTE waiting\fR \|state (p2) will not exceed
  2835. time\(hylimit T21 (see Annex\ D).
  2836. .bp
  2837. .RT
  2838. .sp 1P
  2839. .LP
  2840. 4.1.6
  2841.     \fICall collision\fR 
  2842. .sp 9p
  2843. .RT
  2844. .PP
  2845. Call collision occurs when a DTE and DCE simultaneously transfer a \fIcall 
  2846. request\fR \|packet and an \fIincoming call\fR packet specifying the same 
  2847. logical channel. The DCE will proceed with the \fIcall request\fR and cancel 
  2848. the 
  2849. \fIincoming call\fR .
  2850. .RT
  2851. .sp 1P
  2852. .LP
  2853. 4.1.7
  2854.     \fIClearing by the DTE\fR 
  2855. .sp 9p
  2856. .RT
  2857. .PP
  2858. At any time, the DTE may indicate clearing by transferring across the DTE/DCE 
  2859. interface a \fIclear request\fR packet (see \(sc\ 4.5). The logical channel 
  2860. is then in the \fIDTE clear request\fR state (p6). When the DCE is prepared 
  2861. to 
  2862. free the logical channel, the DCE will transfer across the DTE/DCE interface 
  2863. a \fIDCE clear confirmation\fR packet specifying the logical channel. The 
  2864. logical 
  2865. channel is then in the \fIready\fR state\ (p1).
  2866. .PP
  2867. The \fIDCE clear confirmation\fR \|packet can only be interpreted
  2868. universally as having local significance; however, within some Administrations' 
  2869. networks, clear confirmation may have end\(hyto\(hyend significance. In 
  2870. all cases, 
  2871. the time spent in the \fIDTE clear request\fR state\ (p6) will not exceed
  2872. time\(hylimit\ T23 (see Annex\ D).
  2873. .PP
  2874. It is possible that subsequent to transferring a \fIclear request\fR 
  2875. \|packet the DTE will receive other types of packets, depending upon the 
  2876. state of the logical channel, before receiving a \fIDCE clear confirmation\fR 
  2877. packet.
  2878. .PP
  2879. \fINote\fR \ \(em\ The calling DTE may abort a call by clearing it before 
  2880. it has received a \fIcall connected\fR or \fIclear indication\fR packet. 
  2881. .PP
  2882. The called DTE may refuse an incoming call by clearing it as described 
  2883. in this point rather than transmitting a \fIcall accepted\fR packet as 
  2884. described in \(sc\ 4.1.4. 
  2885. .RT
  2886. .sp 1P
  2887. .LP
  2888. 4.1.8
  2889.     \fIClearing by the DCE\fR 
  2890. .sp 9p
  2891. .RT
  2892. .PP
  2893. The DCE will indicate clearing by transferring across the DTE/DCE interface 
  2894. a \fIclear indication\fR \|packet (see \(sc\ 4.5). The logical channel 
  2895. is then in the \fIDCE clear indication\fR state\ (p7). The DTE shall respond 
  2896. by transferring across the DTE/DCE interface a \fIDTE clear confirmation 
  2897. packet\fR . The logical 
  2898. channel is then in the \fIready\fR state\ (p1).
  2899. .PP
  2900. The action taken by the DCE when the DTE does not confirm clearing
  2901. within time\(hyout T13 is given in Annex\ D.
  2902. .RT
  2903. .sp 1P
  2904. .LP
  2905. 4.1.9
  2906.     \fIClear collision\fR 
  2907. .sp 9p
  2908. .RT
  2909. .PP
  2910. Clear collision occurs when a DTE and DCE simultaneously transfer a \fIclear 
  2911. request\fR \|packet and a \fIclear indication\fR packet specifying the 
  2912. same 
  2913. logical channel. Under these circumstances the DCE will consider that the
  2914. clearing is completed. The DCE will not expect a \fIDTE clear confirmation\fR 
  2915. packet and will not transfer a \fIDCE clear confirmation\fR packet. This 
  2916. places the logical channel in the \fIready\fR state\ (p1). 
  2917. .RT
  2918. .sp 1P
  2919. .LP
  2920. 4.1.10
  2921.     \fIUnsuccessful call\fR 
  2922. .sp 9p
  2923. .RT
  2924. .PP
  2925. If a call cannot be established, the DCE will transfer a \fIclear\fR \fIindication\fR 
  2926. \|packet specifying the logical channel indicated in the \fIcall\fR 
  2927. \fIrequest\fR packet.
  2928. .RT
  2929. .sp 1P
  2930. .LP
  2931. 4.1.11
  2932.     \fICall progress signals\fR 
  2933. .sp 9p
  2934. .RT
  2935. .PP
  2936. The DCE will be capable of transferring to the DTE \fIclearing call\fR 
  2937. \fIprogress\fR \|signals as specified in Recommendation\ X.96. 
  2938. .PP
  2939. \fIClearing call progress\fR \|signals will be carried in \fIclear\fR 
  2940. \fIindication\fR \|packets which will terminate the call to which the packet 
  2941. refers. The method of coding \fIclear indication\fR packets containing 
  2942. \fIcall progress\fR 
  2943. signals is detailed in \(sc\ 5.2.3.
  2944. .RT
  2945. .sp 1P
  2946. .LP
  2947. 4.1.12
  2948.     \fIData transfer state\fR 
  2949. .sp 9p
  2950. .RT
  2951. .PP
  2952. The procedures for the control of packets between DTE and DCE while in 
  2953. the \fIdata transfer\fR \|state are contained in \(sc\ 4.3. 
  2954. .bp
  2955. .RT
  2956. .sp 1P
  2957. .LP
  2958. 4.2
  2959.     \fIProcedures for\fR 
  2960. \fIpermanent virtual circuit service\fR 
  2961. .sp 9p
  2962. .RT
  2963. .PP
  2964. Figures B\(hy1/X.25 and B\(hy3/X.25 show the state diagrams which give 
  2965. a definition of events at the packet layer DTE/DCE interface for logical 
  2966. channels assigned for 
  2967. permanent virtual circuits
  2968. .
  2969. .PP
  2970. Annex C gives details of the action taken by the DCE on receipt of
  2971. packets in each state shown in Annex\ B.
  2972. .PP
  2973. For permanent 
  2974. virtual circuits
  2975. there is no call set\(hyup or
  2976. clearing. The procedures for the control of packets between DTE and DCE 
  2977. while in the \fIdata transfer\fR state are contained in \(sc\ 4.3. 
  2978. .PP
  2979. If a momentary failure occurs within the network, the DCE will reset the 
  2980. permanent virtual circuit as described in \(sc\ 4.4.3, with the cause \*QNetwork 
  2981. congestion\*U, and then will continue to handle data traffic. 
  2982. .PP
  2983. If the network has a temporary inability to handle data traffic, the DCE 
  2984. will reset the permanent virtual circuit with the cause \*QNetwork out 
  2985. of 
  2986. order\*U. When the network is again able to handle data traffic, the DCE 
  2987. should reset the permanent virtual circuit with the cause \*QNetwork 
  2988. operational\*U.
  2989. .RT
  2990. .sp 1P
  2991. .LP
  2992. 4.3
  2993.     \fIProcedures for data and interrupt transfer\fR 
  2994. .sp 9p
  2995. .RT
  2996. .PP
  2997. The data transfer and interrupt procedures described in this
  2998. section apply independently to each logical channel assigned for virtual 
  2999. calls or permanent virtual circuits existing at the DTE/DCE interface. 
  3000. .PP
  3001. Normal network operation dictates that user data in \fIdata\fR \|and
  3002. \fIinterrupt\fR \|packets are all passed transparently, unaltered through the
  3003. network in the case of packet DTE to packet DTE communications. The order of
  3004. bits in \fIdata\fR and \fIinterrupt\fR packets is preserved. Packet sequences 
  3005. are 
  3006. delivered as complete packet sequences. DTE diagnostic codes are treated as
  3007. described in \(sc\(sc\ 5.2.4, 5.4.3 and 5.5.1.
  3008. .RT
  3009. .sp 1P
  3010. .LP
  3011. 4.3.1
  3012.     \fIStates for data transfer\fR 
  3013. .sp 9p
  3014. .RT
  3015. .PP
  3016. A 
  3017. virtual call logical channel
  3018. is in the \fIdata transfer\fR \|state\ (p4) after completion of call establishment 
  3019. and prior to a clearing or a restart procedure. A 
  3020. permanent virtual circuit logical channel
  3021. is
  3022. continually in the \fIdata transfer\fR state\ (p4) except during the restart
  3023. procedure. \fIData\fR , \fIinterrupt\fR , \fIflow control\fR and \fIreset\fR 
  3024. packets may be 
  3025. transmitted and received by a DTE in the \fIdata transfer\fR state of a logical
  3026. channel at the DTE/DCE interface. In this state, the flow control and reset
  3027. procedures described in \(sc\ 4.4 apply to data transmission on that logical
  3028. channel to and from the DTE.
  3029. .PP
  3030. When a virtual call is cleared, \fIdata\fR \|and \fIinterrupt\fR \|packets 
  3031. may be discarded by the network (see \(sc\ 4.5). In addition, \fIdata\fR 
  3032. , \fIinterrupt\fR , 
  3033. \fIflow control\fR and \fIreset\fR packets transmitted by a DTE will be 
  3034. ignored by the DCE when the logical channel is in the \fIDCE clear indication\fR 
  3035. state\ (p7). 
  3036. Hence it is left to the DTE to define DTE to DTE protocols able to cope with
  3037. the various possible situations that may occur.
  3038. .RT
  3039. .sp 1P
  3040. .LP
  3041. 4.3.2
  3042.     \fIUser data field length of data packets\fR 
  3043. .sp 9p
  3044. .RT
  3045. .PP
  3046. The standard maximum user data field length is
  3047. 128\ octets.
  3048. .PP
  3049. In addition, other maximum user data field lengths may be offered by Administrations 
  3050. from the following list: 16, 32, 64, 256, 512, 1024, 2048 
  3051. and\ 4096\ octets. An optional maximum user data field length may be selected 
  3052. for a period of time as the default maximum user data field length common 
  3053. to all 
  3054. virtual calls at the DTE/DCE interface (see \(sc\ 6.9). A value other than the
  3055. default may be selected for a period of time for each permanent virtual 
  3056. circuit (see \(sc\ 6.9). Negotiation of maximum user data field lengths 
  3057. on a per call basis may be made with the \fIflow control parameter negotiation\fR 
  3058. facility (see 
  3059. \(sc\ 6.12).
  3060. .PP
  3061. The user data field of \fIdata\fR \|packets transmitted by a DTE or DCE 
  3062. may contain any number of bits up to the agreed maximum. 
  3063. .PP
  3064. \fINote\fR \ \(em\ Some networks require the user data field to contain an
  3065. integral number of octets (see the note in \(sc\ 3).
  3066. .bp
  3067. .PP
  3068. If the user data field in a \fIdata\fR \|packet exceeds the locally
  3069. permitted maximum user data field length, then the DCE will reset the virtual 
  3070. call or permanent virtual circuit with the resetting cause \*QLocal procedure 
  3071. error\*U.
  3072. .RT
  3073. .sp 1P
  3074. .LP
  3075. 4.3.3
  3076.     \fIDelivery Confirmation bit\fR 
  3077. .sp 9p
  3078. .RT
  3079. .PP
  3080. The setting of the Delivery Confirmation bit (
  3081. D\ bit
  3082. ) is
  3083. used to indicate whether or not the DTE wishes to receive an end\(hyto\(hyend
  3084. acknowledgement of delivery, for data it is transmitting, by means of the
  3085. packet receive sequence number\ P(R) (see \(sc\ 4.4).
  3086. .PP
  3087. \fINote\fR \ \(em\ The use of the 
  3088. D bit procedure
  3089. does not obviate the need for a higher layer protocol agreed between the 
  3090. communicating DTEs which 
  3091. may be used with or without the D\ bit procedure to recover from user or 
  3092. network generated resets and clearings. 
  3093. .PP
  3094. The calling DTE may, during call establishment, ascertain that the
  3095. D\ bit procedure can be used for the call by setting bit\ 7 in the General 
  3096. Format Identifier of the \fIcall request\fR packet to\ 1 (see \(sc\ 5.1.1). 
  3097. Every network or 
  3098. part of the international network will pass this bit transparently. If the
  3099. remote DTE is able to handle the D\ bit procedure, it should not regard 
  3100. this bit being set to\ 1 in the \fIincoming call\fR packet as invalid. 
  3101. .PP
  3102. Similarly, the called DTE can set bit\ 7 in the General Format
  3103. Identifier of the \fIcall accepted\fR \|packet to\ 1. Every network or 
  3104. part of the 
  3105. international network will pass this bit transparently. If the calling 
  3106. DTE is able to handle the D\ bit procedure, it should not regard this bit 
  3107. being set 
  3108. to\ 1 in the \fIcall connected\fR packet as invalid.
  3109. .PP
  3110. The use by DTEs of the above mechanism in the \fIcall request\fR \|and
  3111. \fIcall accepted\fR \|packets is recommended but is not mandatory for using the
  3112. D\ bit procedure during the virtual call.
  3113. .RT
  3114. .sp 1P
  3115. .LP
  3116. 4.3.4
  3117.     \fIMore Data mark\fR 
  3118. .sp 9p
  3119. .RT
  3120. .PP
  3121. If a DTE or DCE wishes to indicate a sequence of more than one
  3122. packet, it uses a more data mark (M\ bit) as defined below.
  3123. .PP
  3124. The 
  3125. M bit
  3126. can be set to 1 in any \fIdata\fR \|packet. When it is
  3127. set to\ 1 in a full \fIdata\fR \|packet or in a partially full \fIdata\fR 
  3128. packet also 
  3129. carrying the D\ bit set to\ 1, it indicates that more data is to follow.
  3130. Recombination with the following \fIdata\fR packet may only be performed within
  3131. the network when the M\ bit is set to\ 1 in a full \fIdata\fR packet which 
  3132. also has the D\ bit set to\ 0. 
  3133. .PP
  3134. A sequence of \fIdata\fR \|packets with every M\ bit set to 1 except for 
  3135. the last one will be delivered as a sequence of \fIdata\fR packets with 
  3136. the M\ bit set to 1 except for the last one when the original packets having 
  3137. the M\ bit set to 1 are either full (irrespective of the setting of the 
  3138. D\ bit) or partially full but have the D\ bit set to 1. 
  3139. .PP
  3140. Two categories of \fIdata\fR \|packets, A and B, have been defined as shown 
  3141. in Table\ 15/X.25. Table\ 15/X.25 also illustrates the network's treatment 
  3142. of the M\ and D\ bits at both ends of a virtual call or permanent virtual 
  3143. circuit.
  3144. .RT
  3145. .sp 1P
  3146. .LP
  3147. 4.3.5
  3148.     \fIComplete packet sequence\fR 
  3149. .sp 9p
  3150. .RT
  3151. .PP
  3152. A complete packet sequence is defined as being composed of a single \fIcategory\ 
  3153. B\fR \|packet and all contiguous preceding \fIcategory\ A\fR packets (if 
  3154. any). \fICategory\ A\fR packets have the exact maximum user data field 
  3155. length with the M\ bit set to\ 1 and the D\ bit set to\ 0. All other \fIdata\fR 
  3156. packets are 
  3157. \fIcategory\ B\fR packets.
  3158. .PP
  3159. When transmitted by a source DTE, a complete packet sequence is
  3160. always delivered to the destination DTE as a single complete packet
  3161. sequence.
  3162. .PP
  3163. Thus, if the receiving end has a larger maximum user data field length 
  3164. than the transmitting end, then packets within a complete packet sequence 
  3165. will be combined within the network. They will be delivered in a complete 
  3166. packet 
  3167. sequence where each packet, except the last one, has the exact maximum user
  3168. data field length, the M\ bit set to\ 1, and the D\ bit set to\ 0. The 
  3169. user data 
  3170. field of the last packet of the sequence may have less than the maximum 
  3171. length and the M and D\ bits are set as described in Table\ 15/X.25. 
  3172. .bp
  3173. .RT
  3174. .ce
  3175. \fBH.T. [T13.25]\fR 
  3176. .ce
  3177. TABLEAU\ 15/X.25
  3178. .ce
  3179. \fBDefinition of two categories of data packets and network treatment
  3180. .ce
  3181. of the M and D bits\fR 
  3182. .T&
  3183. lw(30p) | lw(30p) | lw(18p) | lw(30p) | lw(60p) | lw(30p) | lw(30p) .
  3184.                         
  3185. .T&
  3186. cw(30p) | cw(30p) | cw(18p) | cw(30p) | cw(60p) | cw(30p) | cw(30p) .
  3187. B    0 or 1    0    No    No    0  (see Note 1)    0
  3188. _
  3189. .T&
  3190. cw(30p) | cw(30p) | cw(18p) | cw(30p) | cw(60p) | cw(30p) | cw(30p) .
  3191. B    0    1    No    No    0    1
  3192. _
  3193. .T&
  3194. cw(30p) | cw(30p) | cw(18p) | cw(30p) | cw(60p) | cw(30p) | cw(30p) .
  3195. B    1    1    No    No    1    1
  3196. _
  3197. .T&
  3198. cw(30p) | cw(30p) | cw(18p) | cw(30p) | cw(60p) | cw(30p) | cw(30p) .
  3199. B    0    0    Yes    No    0    0
  3200. _
  3201. .T&
  3202. cw(30p) | cw(30p) | cw(18p) | cw(30p) | cw(60p) | cw(30p) | cw(30p) .
  3203. B    0    1    Yes    No    0    1
  3204. _
  3205. .T&
  3206. cw(30p) | cw(30p) | cw(18p) | cw(30p) | cw(60p) | cw(30p) | cw(30p) .
  3207. A    1    0    Yes    Yes (see Note 2)    1    0
  3208. _
  3209. .T&
  3210. cw(30p) | cw(30p) | cw(18p) | cw(30p) | cw(60p) | cw(30p) | cw(30p) .
  3211. B    1    1    Yes    No    1    T{
  3212. 1
  3213. \ua\d\u)\d
  3214. Refers to the delivered \fIdata\fR
  3215. \| packet whose last bit of user data corresponds to the last bit of user 
  3216. data, if any, that was present in the 
  3217. \fIdata\fR
  3218. packet sent by the source DTE.
  3219. .parag
  3220. \fINote\ 1\fR
  3221. \ \(em\ The originating network will force the M bit to 0.
  3222. .parag
  3223. \fINote\ 2\fR
  3224. \ \(em\ If the \fIdata\fR
  3225.  packet sent by the source DTE is combined with other packets, up to and 
  3226. including a \fIcategory B\fR 
  3227. \| packet, the M and D bit settings in the \fIdata\fR
  3228.  packet received by the destination DTE will be according to that given 
  3229. in the two right hand columns for the last \fIdata\fR 
  3230. packet sent by the
  3231. source DTE that was part of the combination.
  3232. .parag
  3233. T}
  3234. _
  3235. .TE
  3236. .nr PS 9
  3237. .RT
  3238. .ad r
  3239. \fBTable 15/X.25 [T13.25], p.\fR 
  3240. .sp 1P
  3241. .RT
  3242. .ad b
  3243. .RT
  3244. .LP
  3245. .sp 3
  3246. .PP
  3247. If the maximum user data field length is the same at both ends, then
  3248. user data fields of \fIdata\fR packets are delivered to the receiving DTE 
  3249. exactly as they have been received by the network, except as follows. If 
  3250. a full packet with the M\ bit set to\ 1 and D\ bit set to\ 0 is followed 
  3251. by an empty packet, then the two packets may be merged so as to become 
  3252. a single \fIcategory\ B\fR full 
  3253. packet. If the last packet of a complete packet sequence transmitted by the
  3254. source DTE has a data field less than the maximum length, the M\ bit set to 1
  3255. and the D\ bit set to\ 0, then the last packet of the complete packet sequence
  3256. delivered to the receiving DTE will have the M\ bit 
  3257. set\ to\ 0.
  3258. .PP
  3259. If the receiving end has a smaller maximum user data field length than 
  3260. the transmitting end, the packets will be segmented within the network, 
  3261. and the M and D\ bits will be set by the network as described to maintain 
  3262. complete 
  3263. packet sequences.
  3264. .RT
  3265. .sp 1P
  3266. .LP
  3267. 4.3.6
  3268.     \fIQualifier bit\fR 
  3269. .sp 9p
  3270. .RT
  3271. .PP
  3272. In some cases, an indicator may be needed with the user data field to distinguish 
  3273. between two types of information. It may be necessary to 
  3274. differentiate, for example, between user data and control information. An
  3275. example of such a case is contained in Recommendation\ X.29.
  3276. .PP
  3277. If such a mechanism is needed, an indicator in the data packet
  3278. header called the Qualifier bit (Q\ bit) may be used.
  3279. .bp
  3280. .PP
  3281. The use of the 
  3282. Q\ bit
  3283. is optional. If this mechanism is not
  3284. needed, the Q\ bit is always set to\ 0. If the Q\ bit mechanism is used, the
  3285. transmitting DTE should set the Q\ bit so as to have the same value (i.e.\ 0
  3286. or\ 1) in all \fIdata\fR packets of the same complete packet sequence. 
  3287. A complete 
  3288. packet sequence transferred by the DTE to the DCE in this fashion will be
  3289. delivered to the distant DTE as a complete packet sequence having the Q\ 
  3290. bit set in all packets to the value assigned by the transmitting DTE. 
  3291. .PP
  3292. If the Q\ bit is not set by the DTE to the same value in all the \fIdata\fR 
  3293. \|packets of a complete packet sequence, the value of the Q\ bit in any 
  3294. of the 
  3295. \fIdata\fR packets of the corresponding packet sequence transferred to 
  3296. the distant DTE is not guaranteed by the network. Moreover, some networks 
  3297. may reset 
  3298. the virtual call or permanent virtual circuit as described in
  3299. Annex\ C/X.25.
  3300. .PP
  3301. Successive \fIdata\fR \| packets are numbered consecutively (see \(sc\ 
  3302. 4.4.1.1) regardless of the value of the Q\ bit. 
  3303. .RT
  3304. .sp 1P
  3305. .LP
  3306. 4.3.7
  3307.     \fIInterrupt procedure\fR 
  3308. .sp 9p
  3309. .RT
  3310. .PP
  3311. The interrupt procedure allows a DTE to transmit data to the
  3312. remote DTE, without following the flow control procedure applying to \fIdata\fR 
  3313. packets (see \(sc\ 4.4). The interrupt procedure can only apply in the 
  3314. \fIflow\fR 
  3315. \fIcontrol ready\fR state\ (d1) within the \fIdata transfer\fR state\ (p4).
  3316. .PP
  3317. The interrupt procedure has no effect on the transfer and flow control 
  3318. procedures applying to the \fIdata\fR packets on the virtual call or permanent 
  3319. virtual circuit.
  3320. .PP
  3321. To transmit an interrupt, a DTE transfers across the DTE/DCE interface 
  3322. a \fIDTE interrupt\fR \|packet. The DTE should not transmit a second \fIDTE 
  3323. interrupt\fR packet until the first one is confirmed with a \fIDCE interrupt 
  3324. confirmation\fR 
  3325. packet (see Table\ C\(hy4/X.25). The DCE, after the interrupt procedure is
  3326. completed at the remote end, will confirm the receipt of the interrupt by
  3327. transferring a \fIDCE interrupt confirmation\fR packet. The receipt of 
  3328. a \fIDCE\fR 
  3329. \fIinterrupt confirmation\fR packet indicates that the interrupt has been 
  3330. confirmed by the remote DTE by means of a \fIDTE interrupt confirmation\fR 
  3331. packet. 
  3332. .PP
  3333. The DCE indicates an interrupt from the remote DTE by transferring
  3334. across the DTE/DCE interface a \fIDCE interrupt\fR packet containing the 
  3335. same data field as in the \fIDTE interrupt\fR packet transmitted by the 
  3336. remote DTE. A \fIDCE\fR \fIinterrupt\fR packet is delivered at or before 
  3337. the point in the stream of \fIdata\fR packets at which the \fIDTE interrupt\fR 
  3338. packet was generated. The DTE will confirm the receipt of the \fIDCE interrupt\fR 
  3339. packet by transferring a \fIDTE interrupt\fR 
  3340. \fIconfirmation\fR packet.
  3341. .RT
  3342. .sp 1P
  3343. .LP
  3344. 4.3.8
  3345.     \fITransit delay\fR \fIof data packets\fR 
  3346. .sp 9p
  3347. .RT
  3348. .PP
  3349. Transit delay
  3350. is an inherent characteristic of a virtual
  3351. call or a permanent virtual circuit, common to the two directions of
  3352. transmission.
  3353. .PP
  3354. This transit delay is the \fIdata\fR \| packet transfer delay as defined 
  3355. in \(sc\ 3.1/X.135, measured between boundaries\ B\d2\uand B\fI\fI\d\fIn\fR\\d\\u(em\d1\u, 
  3356. as defined in Figure\ 2/X.135 (that means, excluding the access lines), 
  3357. with the conditions given in \(sc\ 3.2/X.135, and is expressed in terms 
  3358. of a mean value. 
  3359. .PP
  3360. Selection of transit delay on a per call basis, and indication to both 
  3361. the calling and called DTEs of the value of transit delay applying for 
  3362. a given virtual call, may be made by the means of the \fItransit delay 
  3363. selection and\fR 
  3364. \fIindication\fR facility (see \(sc\ 6.27).
  3365. .RT
  3366. .sp 1P
  3367. .LP
  3368. 4.4
  3369.     \fIProcedures for flow control\fR 
  3370. .sp 9p
  3371. .RT
  3372. .PP
  3373. Paragraph\ 4.4 only applies to the \fIdata transfer\fR \|state (p4) and 
  3374. specifies the procedures covering flow control of \fIdata\fR packets and 
  3375. reset on each logical channel used for a virtual call or a permanent virtual 
  3376. circuit.
  3377. .RT
  3378. .sp 1P
  3379. .LP
  3380. 4.4.1
  3381.     \fIFlow control\fR 
  3382. .sp 9p
  3383. .RT
  3384. .PP
  3385. At the DTE/DCE interface of a logical channel used for a virtual
  3386. call or permanent virtual circuit, the transmission of \fIdata\fR packets is
  3387. controlled separately for each direction and is based on authorizations from
  3388. the receiver.
  3389. .PP
  3390. On a virtual call or permanent virtual circuit, flow control also
  3391. allows a DTE to limit the rate at which it accepts packets across the DTE/DCE 
  3392. interface, noting that there is a network\(hydependent limit on the number 
  3393. of 
  3394. \fIdata\fR packets which may be in the network on the virtual call or permanent
  3395. virtual circuit.
  3396. .bp
  3397. .RT
  3398. .sp 1P
  3399. .LP
  3400. 4.4.1.1
  3401.     \fINumbering of data packets\fR 
  3402. .sp 9p
  3403. .RT
  3404. .PP
  3405. Each \fIdata\fR \|packet transmitted at the DTE/DCE interface for each 
  3406. direction of transmission in a virtual call or permanent virtual circuit 
  3407. is 
  3408. sequentially numbered.
  3409. .PP
  3410. The sequence numbering scheme of the packets is performed modulo\ 8.
  3411. The packet sequence numbers cycle through the entire range\ 0 to\ 7. Some
  3412. Administrations will provide the \fIextended packet sequence numbering\fR 
  3413. facility (see \(sc\ 6.2) which, if selected, provides a sequence numbering 
  3414. scheme for 
  3415. packets being performed modulo\ 128. In this case, packet sequence numbers 
  3416. cycle through the entire range\ 0 to\ 127. The packet sequence numbering 
  3417. scheme, 
  3418. modulo\ 8 or\ 128, is the same for both directions of transmission and 
  3419. is common for all logical channels at the DTE/DCE interface. 
  3420. .PP
  3421. Only \fIdata\fR \|packets contain this sequence number called the
  3422. packet send sequence number P(S)
  3423. .
  3424. .PP
  3425. The first \fIdata\fR \|packet to be transmitted across the DTE/DCE
  3426. interface for a given direction of data transmission, when the logical 
  3427. channel has just entered the \fIflow control ready\fR state (d1), has a 
  3428. packet send 
  3429. sequence number equal to\ 0.
  3430. .RT
  3431. .sp 1P
  3432. .LP
  3433. 4.4.1.2
  3434.     \fIWindow description\fR 
  3435. .sp 9p
  3436. .RT
  3437. .PP
  3438. At the DTE/DCE interface, a window is defined for each direction of data 
  3439. transmission of a logical channel used for a virtual call or permanent 
  3440. virtual circuit. The window is the ordered set of W consecutive packet send
  3441. sequence numbers of the \fIdata\fR packets authorized to cross the
  3442. interface.
  3443. .PP
  3444. The lowest sequence number in the window is referred to as the
  3445. lower window edge
  3446. . When a virtual call or permanent virtual circuit at the DTE/DCE interface 
  3447. has just entered the \fIflow control ready\fR state (d1), the window related 
  3448. to each direction of data transmission has a lower window edge equal to\ 
  3449. 0. 
  3450. .PP
  3451. The packet send sequence number of the first \fIdata\fR \|packet not
  3452. authorized to cross the interface is the value of the lower window edge 
  3453. plus W (modulo\ 8, or 128\ when extended). 
  3454. .PP
  3455. The standard window size W is 2 for each direction of data
  3456. transmission at the DTE/DCE interface. In addition, other window sizes 
  3457. may be offered by Administrations. An optional 
  3458. window size
  3459. may be selected for a period of time as the default window size common 
  3460. to all virtual calls at the DTE/DCE interface (see \(sc\ 6.10). A value 
  3461. other than the default may be selected for a period of time for each permanent 
  3462. virtual circuit (see \(sc\ 6.10). 
  3463. Negotiation of window sizes
  3464. on a per call basis may be made with the
  3465. \fIflow control parameter negotiation\fR facility (see \(sc\ 6.12).
  3466. .RT
  3467. .sp 1P
  3468. .LP
  3469. 4.4.1.3
  3470.     \fIFlow control principles\fR 
  3471. .sp 9p
  3472. .RT
  3473. .PP
  3474. When the sequence number P(S) of the next \fIdata\fR \|packet to be
  3475. transmitted by the DCE is within the window, the DCE is authorized to transmit 
  3476. this \fIdata\fR packet to the DTE. When the sequence number\ P(S) of the 
  3477. next data packet to be transmitted by the DCE is outside of the window, 
  3478. the DCE will not transmit a \fIdata\fR packet to the DTE. The DTE should 
  3479. follow the same 
  3480. procedure.
  3481. .PP
  3482. When the sequence number P(S) of the \fIdata\fR \|packet received by the
  3483. DCE is the next in sequence and is within the window, the DCE will accept 
  3484. this \fIdata\fR packet. A received \fIdata\fR packet containing a P(S) 
  3485. that is out of 
  3486. sequence (i.e.,\ there is a duplicate or a gap in the P(S) numbering), 
  3487. outside the window, or not equal to\ 0 for the first \fIdata\fR packet 
  3488. after entering the 
  3489. \fIflow control ready\fR state\ (d1) is considered by the DCE as a local 
  3490. procedure error. The DCE will reset the virtual call or permanent virtual 
  3491. circuit (see 
  3492. \(sc\ 4.4.3). The DTE should follow the same procedure.
  3493. .PP
  3494. A number (modulo 8, or 128 when extended), referred to as a 
  3495. packet receive sequence number P(R)
  3496. , conveys across the DTE/DCE interface
  3497. information from the receiver for the transmission of \fIdata\fR packets. When
  3498. transmitted across the DTE/DCE interface, a\ P(R) becomes the lower window 
  3499. edge. In this way, additional \fIdata\fR packets may be authorized by the 
  3500. receiver to 
  3501. cross the DTE/DCE interface.
  3502. .PP
  3503. The packet receive sequence number, P(R), is conveyed in \fIdata\fR ,
  3504. \fIreceive ready\fR \|(RR) and \fIreceive not ready\fR (RNR) packets.
  3505. .bp
  3506. .PP
  3507. The value of a P(R) received by the DCE must be within the range from the 
  3508. last P(R) received by the DCE up to and including the packet send sequence 
  3509. number of the next \fIdata\fR packet to be transmitted by the DCE. Otherwise, 
  3510. the DCE will consider the receipt of this P(R) as a procedure error and 
  3511. will reset the virtual call or permanent virtual circuit. The DTE should 
  3512. follow the same procedure. 
  3513. .PP
  3514. The receive sequence number P(R) is less than or equal to the sequence 
  3515. number of the next expected \fIdata\fR packet and implies that the DTE 
  3516. or DCE 
  3517. transmitting P(R) has accepted at least all \fIdata\fR packets numbered 
  3518. up to and including P(R)\ \(em\ 1. 
  3519. .RT
  3520. .sp 1P
  3521. .LP
  3522. 4.4.1.4
  3523.     \fIDelivery confirmation\fR 
  3524. .sp 9p
  3525. .RT
  3526. .PP
  3527. When the D\ bit is set to 0 in a \fIdata\fR \|packet having P(S) = p, the 
  3528. significance of the returned P(R) corresponding to that \fIdata\fR packet 
  3529. [i.e.,\ P(R)\ \(>="\ p\ +\ 1] is a 
  3530. local updating of the window
  3531. across the
  3532. packet level interface so that the achievable throughput is not constrained 
  3533. by the DTE to DTE round trip delay across the network(s). 
  3534. .PP
  3535. When the D\ bit is set to 0 in a \fIdata\fR \|packet, the returned P(R)
  3536. corresponding to that \fIdata\fR \|packet does not signify that a P(R) has been
  3537. received from the remote DTE.
  3538. .PP
  3539. When the D\ bit is set to 1 in a \fIdata\fR \|packet having P(S)\ =\ p, the
  3540. significance of the returned P(R) corresponding to that \fIdata\fR packet
  3541. [i.e.\ P(R)\ \(>="\ p\ +\ 1] is an indication that a\ P(R) has been received 
  3542. from the 
  3543. remote DTE for all data bits in the \fIdata\fR packet in which the D\ bit had
  3544. originally been set to\ 1.
  3545. .PP
  3546. \fINote\ 1\fR \ \(em\ A DTE, on receiving a \fIdata\fR \|packet with the 
  3547. D\ bit set 
  3548. to\ 1, should transmit the corresponding P(R) as soon as possible in order to
  3549. avoid the possibility of deadlocks (e.g.\ without waiting for further \fIdata\fR 
  3550. packets). A \fIdata\fR , \fIRR\fR or \fIRNR\fR packet may be used to convey 
  3551. the P(R) (see 
  3552. Note to \(sc\ 4.4.1.6). Likewise, the DCE is required to send P(R) to the 
  3553. DTE as 
  3554. soon as possible from when the P(R) is received from the remote DTE. When 
  3555. the DTE is not currently operating the D\ bit procedure, the receipt of 
  3556. a \fIdata\fR 
  3557. packet with the D\ bit set to\ 1 may be treated by the DTE as an error
  3558. condition.
  3559. .PP
  3560. \fINote\ 2\fR \ \(em\ If a P(R) for a \fIdata\fR \|packet with the D\ bit 
  3561. set to 1 is outstanding, local updating of the window will be deferred 
  3562. for subsequent 
  3563. \fIdata\fR packets with the D\ bit set to\ 0. Some networks may also defer 
  3564. updating the window for previous \fIdata\fR packets (within the window) 
  3565. with the D\ bit set to 0 until the corresponding P(R) for the packet with 
  3566. the outstanding D\ bit set to 1 is transmitted to the DTE. 
  3567. .PP
  3568. \fINote\ 3\fR \ \(em\ P(R) values corresponding to the data contained in 
  3569. \fIdata\fR \|packets with the D\ bit set to\ 1 need not be the same at 
  3570. the DTE/DCE interfaces at each end of a virtual call or a permanent virtual 
  3571. circuit. 
  3572. .PP
  3573. \fINote\ 4\fR \ \(em\ If the DTE has sent \fIdata\fR \|packets with the 
  3574. D\ bit set 
  3575. to\ 0, the DTE does not have to wait for local updating of the window by 
  3576. the DCE before initiating a resetting or clearing procedure. 
  3577. .RT
  3578. .sp 1P
  3579. .LP
  3580. 4.4.1.5
  3581.     \fIDTE and DCE receive ready (RR) packets\fR 
  3582. .sp 9p
  3583. .RT
  3584. .PP
  3585. \fIRR\fR \|packets are used by the DTE or DCE to indicate that it is
  3586. ready to receive the W\ \fIdata\fR \|packets within the window starting 
  3587. with P(R), 
  3588. where P(R) is indicated in the \fIRR\fR \ packet.
  3589. .RT
  3590. .sp 1P
  3591. .LP
  3592. 4.4.1.6
  3593.     \fIDTE and DCE receive not ready (RNR) packets\fR 
  3594. .sp 9p
  3595. .RT
  3596. .PP
  3597. \fIRNR\fR \|packets are used by the DTE or DCE to indicate a temporary 
  3598. inability to accept additional \fIdata\fR packets for a given virtual call 
  3599. or 
  3600. permanent virtual circuit. A DTE or DCE receiving an \fIRNR\fR packet shall 
  3601. stop 
  3602. transmitting \fIdata\fR packets on the indicated logical channel, but the 
  3603. window is updated by the P(R) value of the \fIRNR\fR packet. The receive 
  3604. not ready situation indicated by the transmission of an \fIRNR\fR packet 
  3605. is cleared by the transmission in the same direction of an \fIRR\fR packet 
  3606. or by the initiation of a reset 
  3607. procedure.
  3608. .PP
  3609. The transmission of an \fIRR\fR \|packet after an \fIRNR\fR \| packet at the
  3610. packet level is not to be taken as a demand for retransmission of packets 
  3611. which have already been transmitted. 
  3612. .PP
  3613. \fINote\fR \ \(em\ The \fIRNR\fR \|packet may be used to convey across 
  3614. the DTE/DCE 
  3615. interface the P(R) value corresponding to a \fIdata\fR packet which had 
  3616. the D\ bit set to\ 1 in the case that additional \fIdata\fR packets cannot 
  3617. be 
  3618. accepted.
  3619. .bp
  3620. .RT
  3621. .sp 1P
  3622. .LP
  3623. 4.4.2
  3624.     \fIThroughput characteristics\fR \fIand\fR 
  3625. \fIthroughput\fR 
  3626. \fIclasses\fR 
  3627. .sp 9p
  3628. .RT
  3629. .PP
  3630. The definitions of throughput and steady state throughput are given in 
  3631. \(sc\ 4 of Recommendation\ X.135. 
  3632. .PP
  3633. A throughput class for one direction of transmission is an inherent
  3634. characteristic of the virtual call or permanent virtual circuit related 
  3635. to the amount of resources allocated to this virtual call or permanent 
  3636. virtual 
  3637. circuit. It is a measure of the steady state throughput that can be provided
  3638. under optimal conditions on a virtual call or permanent virtual circuit.
  3639. However, due to the statistical sharing of transmission and switching
  3640. resources, it is not guaranteed that the throughput class can be reached 
  3641. 100% of the time. 
  3642. .PP
  3643. The relations between throughput class and the throughput parameters and 
  3644. objectives described in Recommendation\ X.135 require further study. The 
  3645. complete definition of the optimal conditions where the measure of the 
  3646. steady state throughput in relation to throughput class is meaningful also 
  3647. requires 
  3648. further study. Pending the results of these further studies, it cannot be
  3649. guaranteed or verified that a network supporting a given throughput class
  3650. value (64\ kbit/s for instance) offers better performance to its users than a
  3651. network not supporting that throughput class. However, a network may offer a
  3652. guarantee to its users on a contribution basis.
  3653. .PP
  3654. The optimal conditions for measurement include the
  3655. following:
  3656. .RT
  3657. .LP
  3658.     1)
  3659.     the access line characteristics of the local and remote
  3660. DTEs do not constrain the throughput class;
  3661. .LP
  3662.      \fINote\fR \ \(em\ In particular, because of the overhead due to the 
  3663. frame and packet headers, when the throughput class corresponding to the 
  3664. user class of service of the DTE is applicable to a virtual call or permanent 
  3665. virtual 
  3666. circuit, a steady state throughput equal to that throughput class can never 
  3667. be reached. 
  3668. .LP
  3669.     2)
  3670.      the window sizes at the local and remote DTE/DCE interfaces do not constrain 
  3671. the throughput; 
  3672. .LP
  3673.     3)
  3674.     the traffic characteristics of other logical channels at
  3675. local and remote DTE/DCE interfaces do not constrain the throughput;
  3676. .LP
  3677.     4)
  3678.      the receiving DTE is not flow controlling the DCE such that the throughput 
  3679. class is not attainable; 
  3680. .LP
  3681.     5)
  3682.      the transmitting DTE sends only \fIdata\fR \|packets which have the maximum 
  3683. data field length; 
  3684. .LP
  3685.     6)
  3686.     the D bit is not set to 1.
  3687. .PP
  3688. The throughput class is expressed in bits per second. The maximum data 
  3689. field length is specified for a virtual call or permanent virtual circuit, 
  3690. and thus the throughput class can be interpreted by the DTE as the number 
  3691. of 
  3692. full \fIdata\fR packets/second that the DTE/DCE interface.
  3693. .PP
  3694. In the absence of the \fIdefault throughput classes assignment\fR 
  3695. \|facility (see \(sc\ 6.11), the default throughput classes for both directions 
  3696. of transmission correspond to the user class of service of the DTE (see 
  3697. \(sc\ 7.2.2.2) but do not exceed the maximum throughput class supported 
  3698. by the network. 
  3699. Negotiation of throughput classes on a per call basis may be made with the
  3700. \fIthroughput class negotiation\fR \|facility (see \(sc\ 6.13).
  3701. .PP
  3702. \fINote\fR \ \(em\ The sum of the throughput classes of all virtual calls and
  3703. permanent virtual circuits supported at a DTE/DCE interface may be greater 
  3704. than the data transmission rate of the access line. 
  3705. .RT
  3706. .sp 1P
  3707. .LP
  3708. 4.4.3
  3709.     \fIProcedure for reset\fR 
  3710. .sp 9p
  3711. .RT
  3712. .PP
  3713. The reset procedure is used to reinitialize the virtual call or
  3714. permanent virtual circuit and in so doing removes in each direction all 
  3715. \fIdata\fR and \fIinterrupt\fR packets which may be in the network (see 
  3716. \(sc\ 4.5). When a virtual call or permanent virtual circuit at the DTE/DCE 
  3717. interface has just been reset, the window related to each direction of 
  3718. data transmission has a lower window 
  3719. edge equal to\ 0, and the numbering of subsequent \fIdata\fR packets to 
  3720. cross the 
  3721. DTE/DCE interface for each direction of data transmission shall start
  3722. from\ 0.
  3723. .PP
  3724. The reset procedure can only apply in the \fIdata transfer\fR \|state (p4) 
  3725. of the DTE/DCE interface. In any other state of the DTE/DCE interface, 
  3726. the 
  3727. reset procedure is abandoned. For example, when a clearing or restarting
  3728. procedure is initiated, \fIreset request\fR and \fIreset indication\fR 
  3729. packets can be left unconfirmed. 
  3730. .bp
  3731. .PP
  3732. For flow control, there are three states d1, d2 and d3 within the
  3733. \fIdata transfer\fR \|state\ (p4). There are \fIflow control ready\fR \ 
  3734. (d1), \fIDTE reset\fR \fIrequest\fR \ (d2), and \fIDCE reset indication\fR 
  3735. \ (d3) as shown in the state diagram in Figure\ B\(hy3/X.25. When entering 
  3736. state p4, the logical channel is placed in 
  3737. state d1. Table\ C\(hy4/X.25 specifies actions taken by the DCE on the 
  3738. receipt of packets from the DTE. 
  3739. .RT
  3740. .sp 1P
  3741. .LP
  3742. 4.4.3.1
  3743.     \fIReset request\fR \fIpacket\fR 
  3744. .sp 9p
  3745. .RT
  3746. .PP
  3747. The DTE shall indicate a request for reset by transmitting a
  3748. \fIreset request\fR \|packet specifying the logical channel to be reset. 
  3749. This places the logical channel in the \fIDTE reset request\fR state\ (d2). 
  3750. .RT
  3751. .sp 1P
  3752. .LP
  3753. 4.4.3.2
  3754.     \fIReset indication\fR \fIpacket\fR 
  3755. .sp 9p
  3756. .RT
  3757. .PP
  3758. The DCE will indicate a reset by transmitting to the DTE a \fIreset\fR 
  3759. \fIindication\fR \|packet specifying the logical channel being reset and 
  3760. the reason for the resetting. This places the logical channel in the \fIDCE 
  3761. reset\fR 
  3762. \fIindication\fR state\ (d3). In this state, the DCE will ignore \fIdata\fR ,
  3763. \fIinterrupt\fR , \fIRR\fR and \fIRNR\fR packets.
  3764. .RT
  3765. .sp 1P
  3766. .LP
  3767. 4.4.3.3
  3768.     \fIReset collision\fR 
  3769. .sp 9p
  3770. .RT
  3771. .PP
  3772. Reset collision occurs when a DTE and a DCE simultaneously transmit a \fIreset 
  3773. request\fR \|packet and a \fIreset indication\fR packet specifying the 
  3774. same logical channel. Under these circumstances the DCE will consider that 
  3775. the reset is completed. The DCE will not expect a \fIDTE reset confirmation\fR 
  3776. packet and 
  3777. will not transfer a \fIDCE reset confirmation\fR packet. This places the 
  3778. logical 
  3779. channel in the \fIflow control ready\fR state\ (d1).
  3780. .RT
  3781. .sp 1P
  3782. .LP
  3783. 4.4.3.4
  3784.     \fIReset confirmation\fR \fIpackets\fR 
  3785. .sp 9p
  3786. .RT
  3787. .PP
  3788. When the logical channel is in the \fIDTE reset request\fR \|state (d2), 
  3789. the DCE will confirm reset by transmitting to the DTE a \fIDCE reset\fR 
  3790. \fIconfirmation\fR packet. This places the logical channel in the \fIflow 
  3791. control\fR \fIready\fR state\ (d1). 
  3792. .PP
  3793. The \fIDCE reset confirmation\fR \|packet can only be interpreted
  3794. universally as having local significance; however, within some Administrations' 
  3795. networks, \fIreset confirmation\fR may have end\(hyto\(hyend significance. 
  3796. In all cases the time spent in the \fIDTE reset request\fR state\ (d2) 
  3797. will not exceed 
  3798. time\(hylimit\ T22 (see Annex\ D).
  3799. .PP
  3800. When the logical channel is in the \fIDCE reset indication\fR \|state (d3), 
  3801. the DTE will confirm reset by transmitting to the DCE a \fIDTE reset\fR 
  3802. \fIconfirmation\fR packet. This places the logical channel in the \fIflow 
  3803. control\fR \fIready\fR state (d1). The action taken by the DCE when the 
  3804. DTE does not confirm the reset within time\(hyout T12 is given in Annex\ 
  3805. D. 
  3806. .RT
  3807. .sp 1P
  3808. .LP
  3809. 4.5
  3810.     \fIEffects of clear, reset and restart procedures on the transfer\fR 
  3811. \fIof packets\fR 
  3812. .sp 9p
  3813. .RT
  3814. .PP
  3815. All \fIdata\fR \|and \fIinterrupt\fR \|packets generated by a DTE (or the
  3816. network) before initiation by the DTE or the DCE of a clear, reset or restart 
  3817. procedure at the local interface will either be delivered to the remote 
  3818. DTE 
  3819. before the DCE transmits the corresponding indication on the remote interface, 
  3820. or be discarded by the network. 
  3821. .PP
  3822. No \fIdata\fR \|or \fIinterrupt\fR packets generated by a DTE (or the network) 
  3823. after the completion of a reset (or for permanent virtual circuits also 
  3824. a 
  3825. restart) procedure at the local interface will be delivered to the remote 
  3826. DTE before the completion of the corresponding reset procedure at the remote 
  3827. interface.
  3828. .PP
  3829. When a DTE initiates a clear, reset or restart procedure at its local interface, 
  3830. all \fIdata\fR \|and \fIinterrupt\fR packets which were generated by the 
  3831. remote DTE (or the network) before the corresponding indication is transmitted 
  3832. to the remote DTE will be either delivered to the initiating DTE before 
  3833. DCE 
  3834. confirmation of the initial clear, reset or restart request, or be discarded 
  3835. by the network. 
  3836. .PP
  3837. \fINote\fR \ \(em\ The maximum number of packets which may be discarded is a
  3838. function of network end\(hyto\(hyend delay and throughput characteristics 
  3839. and, in 
  3840. general, has no relation to the local window size. For virtual calls and
  3841. permanent virtual circuits on which all \fIdata\fR packets are transferred 
  3842. with the D\ bit set to\ 1, the maximum number of packets which may be discarded 
  3843. in one 
  3844. direction of transmission is not larger than the window size of the direction 
  3845. of transmission. 
  3846. .bp
  3847. .RT
  3848. .sp 2P
  3849. .LP
  3850. 4.6
  3851.      \fIEffects of the physical layer and the data link layer on the\fR \fIpacket 
  3852. layer\fR 
  3853. .sp 1P
  3854. .RT
  3855. .sp 1P
  3856. .LP
  3857. 4.6.1
  3858.     \fIGeneral principles\fR 
  3859. .sp 9p
  3860. .RT
  3861. .PP
  3862. In general, if a problem is detected in one layer (physical, data link 
  3863. or packet layer) and can be solved in this layer according to the DCE 
  3864. error recovery procedures provided in this Recommendation without loss or
  3865. duplication of data, the adjacent layers are not involved in the error
  3866. recovery.
  3867. .PP
  3868. If an error recovery by the DCE implies a possible loss or duplication 
  3869. of data, then the higher layer is informed. 
  3870. .PP
  3871. The reinitialization of one layer by the DCE is only performed if a
  3872. problem cannot be solved in this layer.
  3873. .PP
  3874. Changes of operational states of the physical layer and the data link layer 
  3875. of the DTE/DCE do not implicitly change the state of each logical channel 
  3876. at the packet layer. Such changes when they occur are expliciltly indicated 
  3877. at the packet layer by the use of restart, clear or reset procedures as 
  3878. appropriate.
  3879. .RT
  3880. .sp 1P
  3881. .LP
  3882. 4.6.2
  3883.     \fIDefinition of an\fR 
  3884. \fIout of order condition\fR 
  3885. .sp 9p
  3886. .RT
  3887. .PP
  3888. In the case of a single link procedure, there is an out of order
  3889. condition when:
  3890. .RT
  3891. .LP
  3892.     \(em
  3893.      a failure on the physical and/or data link layer is detected: such a 
  3894. failure is defined as a condition in which the DCE cannot transmit or 
  3895. cannot receive any frame because of abnormal conditions caused by, for
  3896. instance, a line default between DTE and\ DCE;
  3897. .LP
  3898.      \fINote\fR \ \(em\ Short physical layer outages (e.g. loss of carrier) 
  3899. are not considered as physical layer failures by the DCE and the data link 
  3900. layer 
  3901. and packet layer are not informed.
  3902. .LP
  3903.     \(em
  3904.     the DCE has received or transmitted a DISC
  3905. command.
  3906. .PP
  3907. There may be other out of order network\(hydependent conditions such as: 
  3908. reset of the data link layer, expiration of T3\ timer (see \(sc\ 2.4.5.3), 
  3909. receipt or transmission of a DM\ response,\ .\|.\|.\ etc.
  3910. .PP
  3911. In the case of the Multilink procedure, an out of order condition is considered 
  3912. as having occured when it is present at the same time for every 
  3913. single link procedure of the DTE/DCE interface. There may be other out 
  3914. of order network\(hydependent conditions such as the performance by DTE 
  3915. or DCE of the 
  3916. multilink resetting procedure (see \(sc\ 2.5.4.2), loss of multilink frame(s)
  3917. (see \(sc\ 2.5.4.4),\ etc.
  3918. .RT
  3919. .sp 1P
  3920. .LP
  3921. 4.6.3
  3922.     \fIActions on the packet layer when an out of order condition is\fR 
  3923. \fIdetected\fR 
  3924. .sp 9p
  3925. .RT
  3926. .PP
  3927. When an out of order ocndition is detected, the DCE will transmit to the 
  3928. remote end: 
  3929. .RT
  3930. .LP
  3931.     1)
  3932.     a reset with the cause \*QOut of order\*U for each permanent
  3933. virtual circuit; and
  3934. .LP
  3935.     2)
  3936.     a clear with the cause \*QOut of order\*U for each existing
  3937. virtual call.
  3938. .sp 1P
  3939. .LP
  3940. 4.6.4
  3941.     \fIActions on the packet layer during an out of order condition\fR 
  3942. .sp 9p
  3943. .RT
  3944. .PP
  3945. During an out of order condition:
  3946. .RT
  3947. .LP
  3948.     1)
  3949.     the DCE will clear any incoming virtual call with the cause
  3950. \*QOut of order\*U;
  3951. .LP
  3952.     2)
  3953.     for any \fIdata\fR \|or \fIinterrupt\fR \|packet received from the
  3954. remote DTE on a permanent virtual circuit, the DCE will reset
  3955. the permanent virtual circuit with the cause \*QOut of
  3956. order\*U;
  3957. .LP
  3958.     3)
  3959.     a \fIreset\fR \|packet received from the remote DTE on a
  3960. permanent virtual circuit will be confirmed to the remote DTE by
  3961. either \fIreset confirmation\fR or \fIreset indication\fR packet.
  3962. .sp 1P
  3963. .LP
  3964. 4.6.5
  3965.      \fIActions on the packet layer when the out of order condition is\fR 
  3966. \fIrecovered\fR 
  3967. .sp 9p
  3968. .RT
  3969. .PP
  3970. When the out of order condition is recovered:
  3971. .RT
  3972. .LP
  3973.     1)
  3974.     the DCE will send a \fIrestart indication\fR \|packet with the
  3975. cause \*QNetwork operational\*U to the local\ DTE;
  3976. .LP
  3977.     2)
  3978.     a reset with the cause \*QRemote DTE operational\*U will be
  3979. transmitted to the remote end of each permanent virtual
  3980. circuit.
  3981. .LP
  3982. .bp
  3983.